
Ask HN: How have you done internationalization (i18n)? - dpods
We&#x27;ve got a i18n project coming up at my day job. I&#x27;m curious to hear other&#x27;s experiences with completing i18n projects. What worked well, what didn&#x27;t work so well, what would you do differently? Were there any 3rd party tools or services you used?
======
bjourne
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.

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.

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).

------
ThePhysicist
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:

[https://github.com/DPKit/gdpr-
portal/blob/master/src/transla...](https://github.com/DPKit/gdpr-
portal/blob/master/src/translations.yml)

We then have a custom Jinja filter that looks up the translation for a given
word, such as

    
    
        {{'summary'|translate}}
    

In code, we have a simple helper function like this:

    
    
        def t(key, lang):
            return translations[lang].get(key, '[{} not found]'.format(key))
    

In practice we use a slightly more advanced version of this function
([https://github.com/adewes/beam/blob/master/beam/site.py#L91](https://github.com/adewes/beam/blob/master/beam/site.py#L91))
which allows us to also include formatting parameters to allow things like
{{'contact-us'|translate(name='Max',email='max@mustermann.de')}}.

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.

Works quite well for us both on the backend as well as frontend, here's an
example of a website (also open source at [https://github.com/DPKit/gdpr-
portal](https://github.com/DPKit/gdpr-portal)) that uses this method:

DE: [https://dsgvo.dpkit.com](https://dsgvo.dpkit.com) EN:
[https://gdpr.dpkit.com](https://gdpr.dpkit.com)

(we decided to keep the different language versions on separate subdomains for
better usability).

Don't be afraid to write your own solution for simple problems like that, no
need to use 3rd party libraries for everything :)

------
simonpure
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.

[0]
[https://developers.google.com/international/](https://developers.google.com/international/)

Disclaimer: I used to work on i18n and i10n for Google as a country specialist
back in the days.

