Dancing with Localization changes

It happens every Christmas, it’s always coming to town (like Santa!), it's an end of year tradition, probably not as fun as trying to swallow the 12 lucky grapes to attract the fairies at New Year’s Eve ... It’s the ghost of Christmas past, it’s the last minute Localization request !!! 

Year after year this is happening again, again.

It’s Christmas time, it’s the tradition, everything's frozen outside there, but the only thing that it should be frozen it’s not!

We build our Localization and QA strategy under the promise of a frozen build, we look for that date in the calendar as Indiana Jones looked for the Holy Grail, and when we find that milestone in the calendar development team, then we marked it in red, we step back and we squeeze all our localization and QA efforts to accommodate that I’m-possible date. We book translators, testers and we advise to our partners that we will be MIA for a few days. During days we challenge our brain to find the creativity and energy required to answer vendors question, to update glossaries, to attend to developers meetings and to supervise the different communication channels existing in a project. These are long days, hectic days, but it’s worth it, because we see the light at the end of the tunnel. We see the milestone in red where the build is frozen and there won’t be more changes, there won’t be new localization requests, there won’t be new content added to the app…. because after all Apple is preparing also for the Christmas break

Source:www.iclarified.com

And then one day, quietly, when you believe that everything is under control and you are happy that you import all the translated content in your CMS just in time, the most terrifying words Loc proffesionals can hear smash in your face,

“
Hey Miguel, sorry we have added a couple of new keys to the “release” candidate build, but no worries, it’s just a few words. When can we have the translation back in all the languages we support?”

— Any random developer :)

Sounds familiar? I bet you experienced this, I did, unfortunately many many times, a few years ago this kind of things drove my crazy, not anymore, I guess as I get older I look emergencies with different eyes. Over the years I learned (sometimes the hard way) that we (loc people) cannot prevent the changes from happening, therefore the right mindset (in my opinion) is to learn how to “dance” with the changes and how to “dance” with the unexpected requests.

We need to assume that the hidden ostrich head tactic will not work in localization. Neither we can run away ....

If we don’t provide a solution to development teams about how to deal with last minute changes then what it might happen is the following sequence…...  in the dev team they have the scrum master from Belgium and he’ll deal with the translation of French and Dutch (because he has a dutch girl from a city close to the Belgium frontier (Eindhoven) and he “speaks” Dutch), and since the producer is German and there are other nationalities in the team this can be handled totally internally within the team …… oooopsss …. It gives me goosebumps!!!!! This approach is the recipe of glossary inconsistencies. We don’t like last minutes changes, but this other strategy is even worse!, so, the key here in my opinion is to learn how to dance with the changes … and it’s very important to understand that being upset/angry is not the most effective mindset to help others. For this reason I want to share some thoughts about how to deal with these last minutes changes, I hope the next recommendations can help you to learn how to dance with changes!!!

Step 1 - Breath 

Step 2 - Block your lizard brain 

Step 3 - Bite your tongue

Step 4 - Sip of coffee, tea or any other addictive liquid you have around

Step 5 - Smile

Step 6 - Ask (if possible politely) for the new keys, new content, keys refill or whatever it was added

Step 7 - Proofread that content with your language specialist, copywriter or terminology guru. This step is important as when we work under pressure language accuracy or consistency is not a priority for tech teams, but we are the language freaks so we need to pay attention to this

Step 8 - Send an email to your service language provider with a heads-up about some urgent translations needs. Please be aware this step is the key of everything; therefore you need to ensure you have a vendor very flexible. Sometimes you will need to include in your MSA with your partner a paragraph of special fees for “last minute changes”. If you don’t have a flexible vendor in this situation=problems. So do your best to find a flexible vendor and please ensure you have a contingency cost buffer in your budget to pay and appreciate the vendor effort to help you.

Step 9 - Update master glossary if needed (depends on the outcome of step 7)

Step 10 - Prepare Localization instructions for your vendor

Step 11 - WAIT. Yes I said wait, sometimes when everyone is in panic mode the best technique is to wait, observe and think. Why? Because quite often after the last minute changes, there will be another last minute change. I have seen this many times, one change leads to another change, and eventually even a third change. Nothing will upset more a translator (apart of paying them 90 days later the POs) than multiple changes in an urgent request. It will be better to hold a little bit the translation request so we can accommodate additional changes before sending it to our partner. 

If you don’t feel comfortable with this waiting approach, another scenario you can explore might be to warn the translators that there might be an additional update,  but you can express that you feel it’s better to start looking at the file to get familiar with the new keys/content. Somehow with this approach you leave your door open just in case you need to step in more changes.

Step 12 - LQA. Once you have the new keys localised back in your CMS I do strongly recommend that you run a quick LQA sanity check. Quite often changes in a few keys have a domino effect that it might affect other pieces of the software. Unleash all your creativity to hack the schedule and put some time there to do a LQA

Step 13 - Communicate as often as possible with dev team to inform them about potential bugs appearing during the LQA phase so developers can work in the fixes as the bugs are logged in your prefered bug tracking tool. PMI schedule techniques are useful in this framework

Step 14 - Give your localization thumbs-up

Step 15 - Celebrate success (or go back to Step 1 😃)

Have a fantastic day and good luck out there in this complex hyper connected world!

@yolocalizo