One of the most popular sessions during LocWorld events is related to internationalization and localization engineering. The summary below explains why proper internationalization engineering is still hard and what you can do to make it better!
The everyday work of a software developer should take global requirements into account when features are being developed. Visibility at this stage is really important, this includes understanding and communicating with developers about requirements, frameworks, as well as known issues that should be avoided. If you find the issues during development rather than after, it is a lot faster to fix them.
People run into message concatenation issues all the time. Development teams are still appending an ‘s’ for plural forms although it works for English only. Just as your development team expands, continuous education of development teams on localization best practices is essential.
Twenty years from now you will be more disappointed by the things that you didn’t do than by the ones you did do, so throw off the bowlines, sail away from safe harbor, catch the trade winds in your sails. Explore,
Mark Twain
There is no university training in internationalization. Curriculum of computer science does not involve i18n. Developers are not trained to make their programs translatable. Often they are not aware of concatenation issues, plurals, managing the locale, etc. Most companies don’t introduce developers to internationalization until the project requires it. Anytime there’s a pull request, teams should be checking for i18n issues. As opposed to waiting for QA teams to report those issues and send them back to the development team.
I18n should be a core requirement and bring up things that engineers might not have thought of, such as telephone numbers, date formats that vary between regions. Provide immediate feedback to engineers whether bad or good, don’t wait until test phase. Localization teams should be part of the decision making during the product design phase. You need explicit requirements for the different markets. Typically localization managers come from a linguistic background. They have to engage developers, so that they are on their side. They need an engineer champion on their team. This includes providing automation to prevent the process from losing velocity. Developers shouldn’t have to massage the files. You need to be an enabler, you also need to have a lot of patience to change the mindset of the organization in regards of i18n.
Top i18n best practices
- Every message should be externalized and not hard-coded.
- Locale information should be available to the software, so it can be accessed when needed for any part of the i18n process.
- The system wide encodings need to be consistent.
- Test your i18n features.
- Automate what could be automated.
- Take advantage of continuous integration and i18n checklists.
- Have consistent visibility to your issues, e.g. use dashboards.
- Pseudo-localization could be used to test strings in other languages in advance.
Have a question related to internationalization? No problem, we’re glad to help!
