4 ms·

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? Wh

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?

layer8 4y ago
…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.
- LeviticusMB 4y ago
  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.
capableweb 4y ago
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.
- LeviticusMB 4y ago
  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.
withinboredom 4y ago
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?
- duskwuff 4y ago
  > 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.
  - withinboredom 4y ago
    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.
    - duskwuff 4y ago
      > 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".

layer8 4y ago

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

LeviticusMB 4y ago
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.

capableweb 4y ago

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.

LeviticusMB 4y ago
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.

withinboredom 4y ago

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?

duskwuff 4y ago
> 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.
- withinboredom 4y ago
  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.
  - duskwuff 4y ago
    > 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".