71–80 of 102 posts
Earlier quoted context omitted.
In English we have the term potable to designate drinkable water, which comes from an old PIEish verb meaning to drink that no one uses anymore and so it's often confused with "pottable" i.e., to be put into a pot, as in a game of pool (a non-aquatic table sport fyi)
What does PIEish mean?
Smells: * If you're concatenating sentence bits, you're doing it wrong * If you're formatting numbers, dates, times, or durations by hand, you're doing it wrong * If you're formatting strings with placeholders and you don't know the gender and number of your placeholders, your translators are going to have a bad time There are two more important rules that this article doesn't mention * Write long descriptions of wha…
This is completely impractical for anything other than the most static content. Take the most basic line from any single imagined game.
E.g. “Your [Abrams tank] has [fired] a [lead-tipped bullet] at a [green] [dragon].”
Ok, let’s say you have fifteen unit types, five attack types, thirteen types of ammo, thirty enemy type adjectives, and fifty enemy nouns. This is one announcement type out of hundreds in your game (Your green dragon was spotted by an enemy Lizardman! Your attack dirigible is running low on hydrogen!) You’re going to - what - precompose all of this? And pay to have your trillions of lines translated into a dozen languages?
At that point it would seem more cost effective to use your i18n budget to finance some kind of monolingual colony on Mars, and just sell your product there.
Yes, this is going to be hard to concat programmatically, and yes, you’ll likely make some mistakes and might need to rethink some phrasing. One language’s ‘blue’ is another language’s ‘wine dark’. One language’s adjective (he is tall) is another language’s verb (he towers). But “don’t concatenate” is simply not useful advice, because it is not actually actionable for most projects.
People act like i18n is some great moral-ethical challenge, and if you fail, you will mortally offend millions. You won’t. You might sound silly, but people are patient, and you’ll recover.
No matter how hard you try and plan, you will, at some point, get localisation wrong. Oh, you’ve thought of gender? That’s great! What about case? Ok, but that only works for languages with nominative-accusative alignment. What about languages with ergative-absolutive alignment? Or a tripartite system? And this is just nouns - wait until we get to verbs!
Another aspect to be aware of is that English is often much shorter than the equivalent translated text, especially on buttons with text labels. I remember many years ago we used a rough rule of thumb of always doubling the space used for English to ensure there was enough space for the translated text.
Years ago when I worked at Microsoft, they had a "pseudo localization" tool, at least for Visual Studio, that would inject backwards text, longer text, etc... It was gibberish, but it gave QA instant feedback on whether the UI would accommodate the localization process. I did a quick web search, and it appears to be a well-understood practice, even covered in a different Shopify blog: https://www.shopify.com/partners…
A separate toggle to underline everything going through the localization system (or adding some __delimiters__ around it if you don't support rich text) is great for spotting text that is not running through localization yet.
Once you have translations back, a "longest length" translation mode is more useful. It picks the longest translation for each token, no matter what the language. Confusing to look at, but great for seeing only the places where you actually have text-fit issues.
Smells: * If you're concatenating sentence bits, you're doing it wrong * If you're formatting numbers, dates, times, or durations by hand, you're doing it wrong * If you're formatting strings with placeholders and you don't know the gender and number of your placeholders, your translators are going to have a bad time There are two more important rules that this article doesn't mention * Write long descriptions of wha…
> If you're concatenating sentence bits, you're doing it wrong. This is completely impractical for anything other than the most static content. Take the most basic line from any single imagined game. E.g. “Your [Abrams tank] has [fired] a [lead-tipped bullet] at a [green] [dragon].” Ok, let’s say you have fifteen unit types, five attack types, thirteen types of ammo, thirty enemy type adjectives, and fifty enemy noun…
Smells: * If you're concatenating sentence bits, you're doing it wrong * If you're formatting numbers, dates, times, or durations by hand, you're doing it wrong * If you're formatting strings with placeholders and you don't know the gender and number of your placeholders, your translators are going to have a bad time There are two more important rules that this article doesn't mention * Write long descriptions of wha…
Even the very big ones get this wrong. I believe AliExpress still uses the same translation in Dutch for the word “register” as they do for “login” (both can be translated as “aanmelden”). Kind of an important distinction.
Seems like this should be so easy to detect (look for duplicates on the right hand side of the translations where there are none on the left).
Earlier quoted context omitted.
Years ago when I worked at Microsoft, they had a "pseudo localization" tool, at least for Visual Studio, that would inject backwards text, longer text, etc... It was gibberish, but it gave QA instant feedback on whether the UI would accommodate the localization process. I did a quick web search, and it appears to be a well-understood practice, even covered in a different Shopify blog: https://www.shopify.com/partners…
I like to have a "double length" localization mode that doubles the English text; useful for fixing some layout issues while waiting for translations. A separate toggle to underline everything going through the localization system (or adding some __delimiters__ around it if you don't support rich text) is great for spotting text that is not running through localization yet. Once you have translations back, a "longest…
A particularly tricky case of this is with usernames and user defined content. Eg, a notification like "Alice is online" in some languages requires knowing Alice's gender. Which may be something that's not even stored anywhere in the system. There's probably some language out there that requires some other piece of personal info for a correct translation. To make things tricky, try having a multitude of items that yo…
I think most common languages you can either choose between a combo adjective like Alice es activo(a) Or alice es activ@ But honestly as engineers, we should follow the advice of making the stilted constructions. We're already trained as users to expect that anyways from all the other apps. If it's just a monolingual app. Sure go nuts, make it read super fluidly. If you have to localize, just do it the tried and true…
The Polish IM app Gadu-Gadu was monolingual. The user's gender was part of the user profile. Now, virtually all female Polish names end in -a (foreign names aside, there's maybe one or two exceptions). There's a fairly popular male name (Kuba) that ends with -a, and GG did use the feminine verb when showing the notification that he's online.
It's usually a diminutive form, but some people have this as their official name, and people are likely to use a diminutive form in your contacts list.
Earlier quoted context omitted.
Common translation tools would benefit from the ability to input some domain information. Typing in an entire sentence is a sensible start, but oftentimes a lone sentence does not carry enough context. Example: in my language, the term "fresh water" translates to "fresh water" or "sweet water". "Sweet water" is the opposite of saltwater, while "fresh water" would only be used in a context like "water in a tank has be…
Most common translation tools already support this. From GNU gettext where it's called context [0], to FormatJS where it's called a description [1], all translation tools worth their salt support providing additional information about the usage. The problem is generally not on the tooling side but on the awareness side, if the person implementing the feature only speaks one language it's easy to overlook issues that…
tangent: did you know that "institutionalization" also resolves to the English numerical contraction: "i18n"? here's a tool to test for conflicts in other words (a11y, k8s, ets): https://encapsulate.me/writing/e25n.html
I hate these numerical contractions. I have no intuitive knowledge of how many characters words have even if I'm seeing them spelled out, let alone trying to do it in reverse.