A Cost-Saving Localization Tip You Should Know
Length of the post: 784 words Estimated reading time: 7 minutes
I love riding my bicycle; it has become my favorite means of transport. That feeling of freedom that my folding bike gives me, I do not change it for anything in the world!! Every time I use less my car in my travels by city and more my bycicle!
A couple of weeks ago I noticed a strange noise when I changed gear, so I took it to the official service and they found out what was happening; there was a link in the chain that was quite eroded. But when the mechanic tried the new chain, he saw that the problem had not been solved totally.
He continued investigating and saw that one "tooth" of the bike's gear rack was half broken.
He changed the gear rack and ... Problem solved! He found the root of the problem! And this case that seems so obvious about how to act in real life, then, why do not we do similarly when we are localizing a product ?, and more specifically why don't we do it when we are executing the Localization QA phase? Let me elaborate ...
During LQA phase, we received a lot of bugs from the testing teams. Check out HERE previous blog posts about LQA.
Bugs that may be related to:
missing fonts,
truncated texts,
hardcore variables (in the code),
alignment issues in the UI or
it can also be bugs related to the decimal separation symbol ...
There are many bugs that can be found during the LQA phase !!!
Usually, these bugs are fixed "on the fly", but we do not usually spend time asking:
Why we have this bug in our app?
Where do they come from?
We fix it and moving forward, but the problem is that this approach is reactive, it does not focus on finding the root of the problem. We fix the bug, but we do not understand what is the problem that caused the bug.
In the real world, we usually spend time finding the root of the problem. In the virtual world of Localization and QA, unfortunately, this is not so usual.
The equivalent in the real world to the virtual one would have been that the chain of my bicycle had been changed, and a few months from now it would have been broken again since the chain making noise is just the symptom of the real problem (half broken tooth in the gear rack)
If we implement an RCA framework there are a number of good things that will occur in our project, for example
- Cost efficiency. In the long run, if we embrace the mindset of finding the root cause instead of treating the symptom there will be fewer LQA bugs; and since LQA phase tends to be quite expensive we will be seeing how our budget is not spent fixing those ugly and classic LQA bugs
- Timeline optimization. Because we have spent time to analyze and understand which are the problems, it means that we are getting more efficient in the way we code software, and fewer bugs will lead always to less time invested in bug fixing.
Below graphic represent how we can implement an Root Cause Analyse framework in our next globalization project. This technique will help us to be more efficient with our processes and in the long run we will save money in our Loc budgets.
Focus on correcting and remedying root causes rather than just symptoms.
If we are getting an app for the Japanese market it is likely that during the LQA phase we will find bugs related to line break issues ... we can go to our xliff file and manually fix that bug. And in the next sprint we will have the same problem again, and in the next one, and in the next one, and in the next one ... and ...you get the idea 😉
Treating individual symptoms may feel productive. It feels like something is getting done. But if we don’t actually diagnose the real root cause of a problem we’ll likely have the same exact problem over and over and over again.
Conclusion
Remember that, the root cause analysis's objective is to identify the Real Cause of problem, not the symptoms, fortunately, this procedure, this framework will assist us to focus our efforts on the true root causes of our Localization bugs, so that we can avoid their appearance in the future again. And after all, as Benjamin Franklin said “an ounce of prevention is worth a pound of cure”
Have a lovely week and good luck identifying the root cause of the bugs in your projects!
@yolocalizo
In this blog post, I imagine three roles that could become as popular as the Social Media Manager did: AI Workflow Localization Manager, Localization Data Curator and AI Localization Quality Specialist
These roles blend human expertise with AI, pointing to a future where localization jobs look very different from today.