cldr VS ppl-i18n

Creating this mapping is a manual process, and the link contains the reference for the mappings. To establish this mapping, you can find the necessary information by visiting the link.

One problem I stumbled upon frequently is codebases that did not support localized formats, but just assumed a certain format to use, for example through concatenation.

There are capabilities built into the programming languages, which allow to format numbers, currencies, etc. with a specific locale. There are also great resources [1] out there that provide all kinds of formats and localized names for countries, currencies, etc.

[1] Unicode CLDR: https://github.com/unicode-org/cldr

Small addition: If you need the characters in machine-readable form, the source is the CLDR project. For Portuguese, the XML file is here on Github: https://github.com/unicode-org/cldr/blob/master/common/main/pt.xml

This information is false. en-150 in CLDR does not use this Euro English variant. It's just world English (en-001) with 3 adjustments: 24 hour time, currency symbol after the number and European time zone codes. Source. That's it.

> Translation and localization costs money

If you have a fan base, you can leverage it to get some amount of translation done. A lot of users are happy to help the product they like get better. Granted, the quality will not be as good as the quality you get with professional translators.

The article also did not talk about the actual the translation process, which in the case of a product that is released but keeps getting updates, is not trivial.

There are tools that exists, but I personally decided to build a workflow around git, with a python scripts that generates a status of all the translations: https://github.com/jyaif/ppl-i18n#status

The downside is that contributors need to figure out how to use github to contribute. The upside is that it's free, you get auditability, versioning, and the barrier of entry may actually increase the quality of translations.