Translate my website — please!

Getting an application or website localized can make a huge difference in how many potential customers you can reach. Getting your product translated nowadays is easy. But taking the right decisions can be hard.

Choosing the internationalization framework

The younger me would have gone the pragmatic way most developers might take. Let my technology stack decide on i18n framework. Using react lets google for ‘react i18n’ using angular some result of ‘angular i18n’ would be a good fit for sure. Might not be the most clever way to decide on a internationalization framework — but hey — it might get you there. But one thing is sure, the next better technology with the next better ‘tech i18n’ will come…​

Are there better criteria to choose a framework? I would consider:

• Maturity: How long does the project exist? Is there an ecosystem,…
• Active: Last commit? Do pull request get merged?
• Features: Does it do proper i18n? plurals, context, interpolation,…
• Not exclusive: Does it focus on one UI Framework?​

Why is it important for the i18n framework to not be specific to one UI framework you might ask? While it might give you faster and more elegant results on the first days later your requirements might change. Consider you create an additional small service which is using another technology and because of that another i18n framework drops into the mix. As a result you need to learn two internationalization frameworks and your process to localize will get more complicated.​

i18n frameworks to try:

• i18next
• polyglot
• formatjs
• jed
• …

Is i18n enough?

Choosing the optimal i18n framework is great. But honestly this is not enough. The closer the release date gets the more obvious it gets, that instrumenting your code for localization is not enough.

There are more point to address:

• How does the translation process look?
• How do the source files get to the translators and back?
• How you deploy new languages after release?
• How do you handle versioning?

Might be the right time to look at the problem from the opposite. Hey it’s 2017 — lets do localization like it’s 2017 and not 1995…

While there are endless online services that offer you to translate your files, there still is just a handful of services handling the complete service of instrumenting the code, serving your translations, enable proper localization and providing the ordering of translations from third party translation services / agencies.

Choosing the right “localization as a service” provider you might consider:

• Do they have support for frameworks like react, angular. Or do they just have a one-liner script that translates the already rendered output of the source language.
• While the just drop a one-liner script solution might be a tempting offering it might stab you in the back later when your demands grow.
• Can you leave anytime or are you locked in? Can you take your translations with you — and are they somehow reusable.
• Does it support versioning—does it support your deployment cycle.
• How are translation orderings handled. Just order and receive — or can you use of the integrated 3rd party service at its best (Communicate with translators, have selected translators, …)​

Services to try out:

• locize (powered by i18next)
• phraseapp
• bablic
• localizeJS
• poeditor
• …

Conclusion

How we use Javascript has changed a lot in the last years. Think of triumphal procession of single page applications, building mobile application using react-native or building desktop applications with electron. Like our view on Javascript and html changed it might be the right time to consider using services for localization.

---

follow me on:
steemit
twitter