We’ve done a lot of projects in the past nearly all of them needed localization. While as developer we were good in finding a suitable i18n framework (read my last post) we struggled in solving the localization process as a whole.
Start thinking about the localization process early
The biggest mistake one can do is looking on localization as it’s only based on instrumenting your code and extract texts into resource files so you can translate them later.
We did this too often. The requirements are clear: enable the application to be translated later but without time to think more about it. It ends with reaching the release day with an application (non-feature complete and over budget — but this is another topic) ready to be published in one language:
Don’t ship in “denglish”
Means developer english as most terms used where spit our by him/her and not proofread (deadlines you know).
The main cause here is developers work inside their codebase — clear enough that the source files for translation land in the codebase too (i look at you /locales folder). Secretly hidden away and well cultivated to grow.
Stop putting the translations inside your code repository. It does not really belong there. The localization team should have access very early — changing terms and reviewing them on your current build. Even more they should be able to start translating the features already ready for shipping.
Mailing translation files around the world
One day (before release) the responsible for localization will knock at your door and asking for the resource files to be translated. You will hand them out and deep in your mind you know their will be some changes in the last days before release and even more changes after release.
Some weeks later day by day there will land some translated files in your inbox and you will copy them to your repository (didn’t i say you shouldn’t do that?) but there are already a lot of changes. Some terms are not used anymore others are new and not yet translated.
Might be the time for some tooling to help you manage your translations — as your translators “might” be located around the world better don’t bet on a tool you install locally on your machine (but who am i to tell you so?).
But still we shipped our first version with some missing translations. Even if the new translations arrive in a few days…the next release is planned in a few months.
Wouldn’t it be great if we can change or add translations without shipping a new release of our software?
Separate the localization process from the development process
Why not deploying your translation files separated from your software so you can update independently? Oh, i should mention if you do so you want to make sure you can have more then one version of your translations, at least one for the current released version and one for the current development branch.
Isn’t that a little over the top…an extra deployment — doesn’t all this just add more complexity?
locize to the rescue
What if i told you — you should not build this yourself
locize is a new online service that solves the problems we described earlier.
The translations are managed in your locize project and published from there to the locize CDN to be consumed from your application.
The localization team can take care of the translations from the first day and keep up with changes with ease.
The processes are separated. Translations can be updated without the need to release an update of you app.
Further you keep full overview about what is translated and what not — even more if you order translations from the integrated translation providers you also keep track of your open orders.
And even if you decide to export and import translations from your project you never loose control as the tooling helps you when merging by showing you all the changes that are made with a nice diff.
locize helped us to handle the localization process in our projects you really should give it a try: http://www.locize.com
follow me on:
steemit
twitter