When it comes to software localization there are some important parts you have to address.
Where the software code is created, i18n is also to be found. Developers needs to instrumentalize the code to be able to be localized to various languages and regions.
There are a lot of questions that should be answered here.
To answer the questions about i18n, you will finally probably use a corresponding i18n framework that meets your needs.
The biggest mistake one can do is looking on software localization as it’s only based on instrumenting your code and extract texts into resource files so you can translate them later.
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 ready to be published in one language.
When the code is ready to be localized, someone needs to translate the content.
You can have your translation done by freelancers, agencies or in-house employees. You can also start with some machine translation, but a translator should at least proofread the machine translated texts.
Text translations are just one element in the localization process. You may also think of images, documents that differs not only for different languages, but also for different countries or regions.
After having internationalized the code and knowing how the content is translated, how will these 2 parts interact with each other?
One day (before release) the responsible for localization will knock at the developer's door and asking for the resource files to be translated. The developer will hand them out and deep in their mind the developer knows there will be some changes in the last days before release and even more changes after release.
Some days/weeks later, the translated files will be ready and the developer will copy them to the repository 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.
Translation Management Systems are a great help. But still there is a gap between development and translation process. Files need to be exported / imported / merged and all while new content get added to be translated. The chaos is inevitable.
There are a lot of translation management systems, choose the one that fits your needs.
Modern translation management systems focuses on continuous localization.
New content in your application should be immediately available in your translation management tool for your translators and newly finished translations should be passed down to the application without a developer needing to add a file to the repository or accepting a PR from the translation management.
Because software development never stops when the first version of a product is released (bug fixes, minor updates and at some point major new versions and releases) — continuously. Your localization and translation process should follow the same pattern as your software development. You should be able to deploy your translation files separated from your software so you can update and manage them independently. And if you do so, you have 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. That way your technical writers and translators can take care of the translations from the first day and keep up with changes with ease. By doing this it is even possible to change or add translations without shipping a new release of your software!