Tips for handling minor regional spelling variations within the same language?

Help each other
#1

My source language is English, and I’m primarily using Localazy to translate to other languages. However, my site supports several English locales, which have just a few regional spelling variations. e.g., “color” vs “colour” and “aluminum” vs “aluminium” differ across en-US, en-GB, en-CA. I don’t want to be constantly reviewing/approving the “translations” to these languages because they’re identical to the source, except for a couple words. I want to be able to specify just a few overrides on the source language, rather than a complete translation. Does anyone have tips on a good workflow for handling these minor differences between locales within the same language? Does Localazy have some options or recommendations for this that I’ve missed, or should I handle this in code instead?

#2

We would love to add a language-specific hidden feature in the future. It would allow you to hide what you don’t want to translate just for a single language. At the moment, this is only possible across all languages.

Anyway, I believe that if you don’t need the language to be 100% translated (just for the sake to have the progress bar full green :-)), you can just translate what needs to be different since Localazy uses the source language translation for the untranslated keys by default when generating output file. It should work perfectly as long as we only talk about regional variants of English and you haven’t enabled filter_untranslated.

There are also other options:

  • “Android-way” - just translate what needs to be different, and revert to the default/parent locale for untranslated keys. This may, however, require a change to the localization-related source code.

  • Another option is downloading files and merging them together using the chained external command. It’s actually a very common scenario that Localazy CLI is a part of a more complex workflow, and downloaded files are altered - typically using Linux commands such as jq for JSON, etc.

#3

Thank you for the reply @vaclav! Those all sound like reasonable options. I do already have code in place to merge translated languages with the source language at build time so that I won’t have key misses if I haven’t yet downloaded translations for some keys. It sounds like filter_untranslated might work well with this setup. I’ll give it a shot!