We use next-intl to handle translations, and Crowdin as an optional web interface for making the act of translating a bit easier.
We would love more language support, even if these languages are used in high-impact areas (e.g. Germany being advanced composters means German doesn’t make much prioritise to support on Peels). That’s because we’ve already built out the infrastructure to support a bunch.
If you’re particularly keen to add a language to Peels, please weigh up whether you can commit to both adding all the current strings and being available to occasionally add new ones.
Any new languages need to be added to the list of accepted locales in config.ts.
As you can see above, we’re simplifying our language support to just the two letter code level. So es for Spanish, not es-ES, es-AR, etc. Like other bootstrapped platforms (e.g. WOOFF), this helps keep complexity down.
We can revisit region support (e.g. Argentinian Spanish, Brazilian Portuguese) further down the line if we have enough users to warrant it, and the differences in regions can’t be ‘smoothed over’ in simplified root language support.
Having Crowdin means anyone with a computer can contribute to Peels’ internationalisation efforts. You don’t need to code. Here’s how it works:
The crowdin.yml file looks for /messages/en.json as the source and creates or looks for translation files in the /messages/%two_letters_code%.json pattern.
Crowdin makes a i18n-sync branch (and pull request into main) each time it detects new translations.
next-intl will fall back to English strings when other languages do not have strings for those new keys yet. This avoids build and rendering issues whilst we wait for translations to come in (at the cost of showing English in some parts to a mostly other-language interface).
Example of using deepmerge to fallback to English when translations aren’t yet in.
Otherwise it would look something like this.