Hacker News Reader

Comment by LeviticusMB | Hacker News Reader

Making localized web apps is such a pain and too often an afterthought. But what if it took almost no extra effort to make the app localized from the start?

What if you could get static type checking, key documentation and code completion right in VS Code?

And what if the translations could be generated using an actual programming language, and even represent HTML markup and not just plain strings?

View on HN

Sounds like a great idea for translators who are also programmers, or at least knows HTML (and syntax for logic, judging by your examples). But I haven't worked in any companies where the translators/the people doing localization have been programmers, they have just been translators. This will be more or less impossible for them to use efficiently, if at all.

Well, you have to start somewhere. Anyone can learn how to call a function, just like they can learn MessageFormat. And basic HTML is something translators must already know.

…then translators need to be programmers, or vice versa. That may not scale to many languages/large products.

What would be useful is the ability to interactively see a systematic set of examples of what the templates one is editing evaluate to.

Example parameters for a specific key and the ability to preview the different translations based on those examples is something I wished for.

But since my translations are code, it basically means I would have to invoke a debugger on the full program, so that's a drawback.

On the other hand, since my translations are code I suppose I could just add something like a unit test or something.

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?

> 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