Establishing localization guidelines, simple scheduling and the Groundhog day mindset ...
A few weeks ago I had a meeting with a product manager with whom we were creating a roadmap; and in that meeting 2 topics emerged, which are repeated again and again; These comments did not catch me by surprise, but what if in a certain way surprises me is that they are the same comments I heard 20 years ago when I was taking my first baby-steps in this industry. Those comments are:
-Localization is expensive
-Scheduling about what happens and when is a black box. It is never clear
So this week in my post I will attack these points! I will explain why localization can be expensive and how to create a basic schedule of localization tasks required to release an application (or any type of software in general). Hopefully, this might bring some visibility and awareness about those topics ... topics that are like the Groundhog day movie. They always end up returning!
The localization process is expensive
Honestly, I do not think is expensive; Prices per word, an hour of LQA, PM fees etc are not expensive. Just with the price of a beer I enjoy in Stockholm with my lovely colleagues, I could actually translate up to 100 words in FIGS 🙂; that can be the content of new words of a whole sprint of 2 weeks in a casual app! Expensive is a subjective concept, but I can understand that the localization phase can be expensive if the process is not handled effectively.
And what does it mean to manage the process effectively? for me it means to be aware of at least these 10 actions ….
It means localization guidelines has been established
It means the initial product has considered localization as part of the product cycle
It means localization QA is part of the scheduling processes
It means there is a clear understanding that localization should start once the product functionality is stable.
It means localization for playtest languages or pseudo-localization is in the schedule
It means that it has been understood that Localization should start once the software functionality is stable.
It means there is an understanding of UI / UX best practices
It means that it has been understood that Localization for other languages will start once the UI is stable.
It means a deadline, a frozen UI mindset is in place. Because this will give time to localization teams to finish translating the software and reference files on time; and working with final material. Nothing is more annoying for a translator or a localization team than receiving an update of a piece of content you are translating or your just finished translating recently!
It means that it is understood that quality aims at source; and to make localization not expensive is important to keep in mind the quality of the English text. Simple grammar English. Short sentences are going to help enormously to avoid corrections in the English content. Corrections in English text slow down the process and it might have a costly impact on budgets. Especially if changes in the English content are introduced while translation is on-going
I believe that if all these points summarized above are understood, the localization phase does not have to be necessarily expensive...
Scheduling
Gone are the days that we first worked on the English product and then we started with the translated version.
The delta between launches in different markets has been reduced dramatically, and actually, in many situations products are launched globally at the same time! This is known as sim-shipping.
Now the question is ... how do we schedule the different Globalization tasks needed to release a product with this sim shipping mindset? and this is the question that popped into this meeting I referred to with the product owner.
"Schedule in localization is like a black box, I throw something there ... but I do not know what happens in there ..."
When is the right moment to think about Culturalization, about internationalization, when translation should start? what about the QA phase, when do we do that? And what about the fixing bugs phase? when does that happen?
All these are valid questions ... and honestly, I understand not having a clear understanding about what happens and when, it can create this feeling of a black box. So let's put a little light on this black box ... let's see if I can explain in a simple way what happens inside that box when it comes to scheduling, maybe we'll end up in a situation not so black!
Full Globalization of an app is more complex than many people that approach our industry for the first time might imagine. There are many processes to carry out and multiple interactions between stakeholders and between translators.
For this reason, and with the hope of clarifying the subject of the Scheduling phase, I have created this chart below, which represents the different tasks we should take into account to plan a localization project. My hope is that this graph will help to open that black box to which the product owner referred ... I believe this chart will help (I hope) to understand the sequence of tasks we must perform and when they happen.
www.yolocalizo.com
For reasons of making this post and the graphics understandable and easy to “digest”, I have not subdivided the tasks that are done during the different phases of culturalization, internationalization etc... but if you are interested in knowing what is done in each phase, just search for those phases in my blog, go to the search section and browse from there; probably there’ll appear a list of the posts I have published related to that topic! And if you feel something is missed or not clear enough ping me and I’ll happily create a post about it! always looking for ideas for new content to create on my blog, so feel free to reach out if something is missing!
The localization of a software project does not have to be especially expensive, if we follow the best practices of the industry the cost will be directly related to the volume to be translated ... and today, the rates are quite competitive for many languages; and localization technology can help us to have very controlled production costs. Contrary to that scenario, if we have a development cycle of an app that considers the translation phase as an afterthought, if the source text changes continuously, if we do not prepare our code to receive future translations (i18n) ... then yes, then we shall be prepared for much back and forth and high cost related to re-translation or related to more QA passes. We will have stakeholders who will tell us that the localization process is expensive (and they’ll be right!).
Regarding the schedule and being a black box ... designing a schedule that takes into account the localization phase does not have to be an art! If we follow the guidelines I created above, it can help us to have in the same schedule the development cycle of an app and how the Localization team will serve and support that development cycle.
And that's what I wanted to blog about this week, 20 years ago I was hearing that localization was expensive and the schedule sim-shipping mindset was not easy to implement ... and recently I've heard it again ... but .... 20 years ago I did not have a blog that could reach thousands of people, now yes 🙂, so maybe 20 years from now, future generations of globalizers will not have to face explaining these issues over and over again ... hopefully that’ll be the case. Anyways lucky everyone! 😎
@yolocalizo
In this post, I explore how chatGPT can become your devil’s advocate in localization, helping you challenge assumptions and think beyond the obvious