We've got a i18n project coming up at my day job. I'm curious to hear other's experiences with completing i18n projects. What worked well, what didn't work so well, what would you do differently? Were there any 3rd party tools or services you used?
It is really, really hard to do i18n really well. Most developers think it is easy because they don't consider all the little details that you need to get right. It's everything from input fields using comma or period as the decimal separator, Sunday or Monday as the start of the week, to currencies, different line lengths, time formats and much more.<p>IMHO, unless you plan to support more than half a dozen locales, it is less work to do one website (or frontend) for each locale than it is to build one website that adapts to multiple locales.<p>Good enough i18n is much easier. Just keep all strings in an associative array: {("greet", "en") : "Hello", ("greet", "ru") : "Здравствуйте!"} then each time a message is to be printed, have a function that looks up the correct translation: i18n_lookup(string_key, language).
I recommend to keep things simple whenever possible. For most of our website projects we use simple dictionaries that we typically store in YAML files, just like this:<p><a href="https://github.com/DPKit/gdpr-portal/blob/master/src/translations.yml" rel="nofollow">https://github.com/DPKit/gdpr-portal/blob/master/src/transla...</a><p>We then have a custom Jinja filter that looks up the translation for a given word, such as<p><pre><code> {{'summary'|translate}}
</code></pre>
In code, we have a simple helper function like this:<p><pre><code> def t(key, lang):
return translations[lang].get(key, '[{} not found]'.format(key))
</code></pre>
In practice we use a slightly more advanced version of this function (<a href="https://github.com/adewes/beam/blob/master/beam/site.py#L91" rel="nofollow">https://github.com/adewes/beam/blob/master/beam/site.py#L91</a>) which allows us to also include formatting parameters to allow things like {{'contact-us'|translate(name='Max',email='max@mustermann.de')}}.<p>You can also keep date and number formats in the i18n dictionary to internationalize dates. Most internationalization libraries do not provide much more than that and try to be overly clever by e.g. offering automated pluralization etc. but in my experience they often subtly break things.<p>Works quite well for us both on the backend as well as frontend, here's an example of a website (also open source at <a href="https://github.com/DPKit/gdpr-portal" rel="nofollow">https://github.com/DPKit/gdpr-portal</a>) that uses this method:<p>DE: <a href="https://dsgvo.dpkit.com" rel="nofollow">https://dsgvo.dpkit.com</a>
EN: <a href="https://gdpr.dpkit.com" rel="nofollow">https://gdpr.dpkit.com</a><p>(we decided to keep the different language versions on separate subdomains for better usability).<p>Don't be afraid to write your own solution for simple problems like that, no need to use 3rd party libraries for everything :)
Google has some great resources including a few open source projects [0]. I don't use any of them directly, but they have been a great inspiration to learn from their epxerience.<p>[0] <a href="https://developers.google.com/international/" rel="nofollow">https://developers.google.com/international/</a><p>Disclaimer: I used to work on i18n and i10n for Google as a country specialist back in the days.