Hacker News Reader

Comment by withinboredom | Hacker News Reader

One solution is to use your native language as the key. Bam, you have context in the code and when testing. No need for shenanigans (and this is how it was done until someone decided to popularize opaque keys in the last decade or so, in fact, most battled-hardened and old libraries expect it to be done that way). You can translate English to English (or whatever) if you want to be able to change the wording without having to retranslate everything… but then if you are changing the wording for the native language, don’t you have to retranslate everything anyway?

View on HN

> One solution is to use your native language as the key.

That fails pretty badly in two cases:

1) If significant changes to the English (or whatever) version need to be made, keeping the original text may be more confusing than useful.

2) When the native-language version is ambiguous in a way that doesn't apply to other languages, e.g. when translating to languages with grammatical gender, or when a single English word can be used in multiple unrelated ways.

1. Is easily “fixed” by a very powerful feature called “search and replace.” As most translation source files (po/json/YAML) are human readable, once all the translations are done, changing the key is remarkably straightforward.

2. You usually (or it’s recommended to) translate entire phrases. Older systems like gettext use context and namespaces to differentiate source keys in a way that is helpful for various things. I believe this is (or should be) a non-problem for any modern system as well.

> 1. Is easily “fixed” by a very powerful feature called “search and replace.”

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

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.

Users of modern systems obviously fail with the context problem. The translators of many websites either didn't know or didn't care whether "comment" and "reply" were used as nouns or verbs, just to take a really common example.

Yeah, naming each translation with a key is definitely the way to go. Apps are full of buttons and labels and short sentences so context is absolutely necessary.

Reply on news.ycombinator.com