Re:Show HN: Localization and translations should be code, no...
by withinboredom on Wednesday July 06, 2022 @03:59AM
(#31998046)
Sure. This is how we do it at work. We have a function, let’s call it fixme(). When you want to change a string, say, “example,” to “sample.” You call fixme(“example”, “sample”). The implementation sees if “sample” == “sample” for non-English. If so, it uses the old translation. A few weeks later, we remove the fixme and old string. There’s a job that pings you about it in Slack so you don’t forget, IIRC. You don’t even need a pre-commit review to fix them.
Words used alone or need context should use the i18n libraries context abilities. Like p_(“clear”, “verb”) and p_(“clear”, “noun”). It’s also helpful to add comments and your translation system should be able to pick them up:
// translators: %d is an amount of money
If you are using a modern translation system that doesn’t support these features, perhaps “downgrading” to an older system is a good idea.
True, but reconciling translation files based on different keys can get messy. Using keys which aren't directly tied to the original language solves this.
> 2. You usually (or it’s recommended to) translate entire phrases
The kind of situation I'm thinking of is words that are used alone, but which are disambiguated by context -- for example, "clear" could be an action meaning "remove everything", or a synonym for "transparent", or an odd term for "approve".