Live data from Hacker News

Lessons From Linguistics: i18n Best Practices for Front-End Developers

shopify.engineering

51–60 of 102 posts

Re: Lessons From Linguistics: i18n Best Practices for Front-End Developers

#51
post #48

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.

Re: Lessons From Linguistics: i18n Best Practices for Front-End Developers

#52
post #2

In general a good short rule of thumb is to always always _always_ write out the full sentence you want to translate and use the tooling to interpolate everything you want to put in it. That way the translator always sees the full context and you make it harder (although not impossible) for yourself to shoot yourself in the foot. Another recommendation I would add is to use two meta locales in development in addition…

A third dev locale worth considering is one which consists of random emojis. Makes it very easy to find hardcoded strings.

Re: Lessons From Linguistics: i18n Best Practices for Front-End Developers

#53

Earlier quoted context omitted.

The code example should rather be an example of what not to do. This method of concatenating different parts of sentences would fall short for any language where the adjective and noun change the form depending on each other and the context (ex. cases). Most Slavic languages make heavy use of this concept. The solution is to just have the full sentence as a single string and let the translation team write it out in i…

Oh, BTW. This is how not to do it: print("The white horse") I would gently suggest taking the spirit of our Ts and Cs into account, when critiquing others. I was simply sharing a quick technique that may not be known by some folks (the "$" in sprintf). It can definitely have uses. I've been writing localized software for over thirty years. I worked for a Japanese corporation that localized into more than 20 languages…

> There's a teensy little chance that I may have something valid to contribute to the topic.

That may be true, but the criticism of GP still stands.

Yes, in some special situations your approach might be the only viable one (just as how in every codebase you sometimes have to cut corners), but GP is right in pointing out that this is a problematic approach, especially without qualification ("only use this if ...").

Re: Lessons From Linguistics: i18n Best Practices for Front-End Developers

#54
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 what the thing is that you're asking someone to translate (button label, menu item, dialog header...), and include a screenshot. Translating very short strings without context is very difficult.

* Ask your translators to do a global once-over QA pass once in a while to detect inconsistencies and weirdness. Once I dealt with a product that had three tabs, and two of the tabs were translated identically. Each tab header translation made sense on its own, but as distinct tab headers side by side, it made no sense to use the same word.

Re: Lessons From Linguistics: i18n Best Practices for Front-End Developers

#55
I think the Polish example is even a bit more complex than that: it's not really that Polish has a separate form for "a few". That's the regular plural form. It's that Polish uses the genitive plural with certain numerals, instead of the nominative. That is, instead of saying "5 dogs" you say "5 of dogs".

This doesn't, to my knowledge, apply if there is no numeral provided, even if we're talking about 1000 dogs, so it wouldn't be right to call it a plural.

Of course, the point of the article still stands.

Disclaimer: I don't speak Polish. I did learn some Czech though at some point (most of which I've forgotten).

Re: Lessons From Linguistics: i18n Best Practices for Front-End Developers

#56

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 way

Re: Lessons From Linguistics: i18n Best Practices for Front-End Developers

#57

Earlier quoted context omitted.

The code example should rather be an example of what not to do. This method of concatenating different parts of sentences would fall short for any language where the adjective and noun change the form depending on each other and the context (ex. cases). Most Slavic languages make heavy use of this concept. The solution is to just have the full sentence as a single string and let the translation team write it out in i…

Oh, BTW. This is how not to do it: print("The white horse") I would gently suggest taking the spirit of our Ts and Cs into account, when critiquing others. I was simply sharing a quick technique that may not be known by some folks (the "$" in sprintf). It can definitely have uses. I've been writing localized software for over thirty years. I worked for a Japanese corporation that localized into more than 20 languages…

[flagged]

Re: Lessons From Linguistics: i18n Best Practices for Front-End Developers

#58

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…

Seamlessly embedding user-generated content into template text is a losing battle. There are always going to be users who test the waters with emojis, zalgo text, l33tspeak profanity, SQL/XSS injection attempts, copypastas, and so on. In the face of such merry nonsense, linguistic idiosyncrasies like proper gendered forms are moot concerns.

Re: Lessons From Linguistics: i18n Best Practices for Front-End Developers

#59
post #53

Earlier quoted context omitted.

Oh, BTW. This is how not to do it: print("The white horse") I would gently suggest taking the spirit of our Ts and Cs into account, when critiquing others. I was simply sharing a quick technique that may not be known by some folks (the "$" in sprintf). It can definitely have uses. I've been writing localized software for over thirty years. I worked for a Japanese corporation that localized into more than 20 languages…

> There's a teensy little chance that I may have something valid to contribute to the topic. That may be true, but the criticism of GP still stands. Yes, in some special situations your approach might be the only viable one (just as how in every codebase you sometimes have to cut corners), but GP is right in pointing out that this is a problematic approach, especially without qualification ("only use this if ...").

Yes, but don’t you think it might be little more diplomatic to say something like:

> While this is an interesting way to allow a translator to arrange the order of terms, there’s a great deal more involved, like … , so we should probably avoid using this technique, if at all possible. It’s always a much better idea to allow translators to work on an entire sentence or paragraph.

See? We get to show off our expertise, without throwing shade on others.

BTW: I have learned, the hard way, that cultural and human sensitivity, as well as basic respect and kindness, are important, when localizing.

But I guess those values are kinda “last century,” and don’t really have any value, in today’s hyper-competitive world.

Re: Lessons From Linguistics: i18n Best Practices for Front-End Developers

#60
post #57

Earlier quoted context omitted.

Oh, BTW. This is how not to do it: print("The white horse") I would gently suggest taking the spirit of our Ts and Cs into account, when critiquing others. I was simply sharing a quick technique that may not be known by some folks (the "$" in sprintf). It can definitely have uses. I've been writing localized software for over thirty years. I worked for a Japanese corporation that localized into more than 20 languages…

[flagged]

Nah, I’m done here. Have a great day!
Post reply on HN