Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

shopify.engineering

Post reply on HN
Print view View original

61–70 of 102 posts

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

#61

Post by p3rls »

worklaptopacct wrote: post #31
Etheryte wrote: 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…

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…

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)

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

#62

Post by post-it »

ChrisMarshallNY wrote: post #14

I've found that I need to support localization from the very start. I never display a quoted string. I always use Apple's tokenization (or create my own, if doing server code). Apple has terrific support for localization, which puts the onus on us, to honor it. I have some basic extensions that I use to support localization in my coding[0-2], but there's also just stuff I need to keep in mind, all the time. There has…

I don't see how this generalizes. If this is supposed to work for any "the {modifier} {subject}" phrase, it won't, because if you want to say "the white cow" you'll end up with "Le vache blanche," which is wrong.

You could store `(format: "%3$@ %1$@ %2$@", modifier: "blanc", subject: "cheval", article: "Le")` but now you've got so many gender associations to keep track of, and a phrase that will still only work as a subject (because in German, all of the words will change if the white horse is the object of the sentence).

EDIT: Oh you're just talking about sprintf specifically, I see what you mean. I agree with your other comment that it's ideal to pass entire sentences to the translators when possible, which is what I'm getting at here too.

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

#63

Post by Tainnor »

ChrisMarshallNY wrote: post #59
Tainnor wrote: post #53

Earlier quoted context omitted.

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

I don't know, I personally value directness more than a "compliment sandwich". And I don't consider criticism of code to be criticism of one's person or expertise. It may be a cultural thing (I'm German).

But you'll have to take that up with the person you originally replied to.

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

#64

Post by dejj »

jimmywetnips wrote: post #56
dale_glass wrote: post #35

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…

@ as a superposition of “a” and “o”; very nice.

If gender is how we sneak conditional expressions and nondet Prolog predicates into natural languages, then I’m in.

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

#65

Post by dejj »

p3rls wrote: post #61
worklaptopacct wrote: post #31

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…

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?

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

#66

Post by FlorianZysset »

Unrelated but I had a weird experience navigating to this article on my IPhone: the music in my headset switched to call mode. I can reproduce that about 50% of the time.

Is there something using the microphone somewhere? Feels really weird…

14 Pro Max with latest beta software

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

#67

Post by troad »

imran-iq wrote: post #43
sergioisidoro wrote: post #24

It's frustrating that the post does not provide any solution for some of the problems like declinations and gender. I internationalised a couple of applications, and it's incredible how i18n frameworks are still so limited in linguistic aspects that are so important for so many languages. Finnish, for example works with a ton of suffixes, and you end up having to rewrite the copy (to non natural structures) to fit in…

Good news is folks are working on better tooling, for example fluent[0] by mozilla. The bad news though is adoption. --- 0: https://projectfluent.org/

Fluent is terrible. I excitedly implemented it in my most recent app, and immediately ran into so many issues.

1) It can transclude variables in translation strings, but these variables cannot themselves be localised. This makes Fluent completely useless for constructions like “Your knight has killed a dragon with a crossbow” in any language with case or gender, unless you pre-translate every possible combination in advance. Which is absurd - the possible combinations almost immediately grow astronomical.

2) The parser is extremely sensitive, and it produces errors which are terse and difficult to debug. Something as basic as a localisation key appearing twice throws an unrecoverable exception.

3) The input files mandate a weird arrangement of new lines for even the simplest branching (e.g. 1 -> cat, 2+ -> cats), which makes them become incredibly difficult to follow. I quickly lost track of my own reference English file - good luck giving them to translator to figure out for any languages with greater grammatical complexity.

4) The documentation is too Spartan to know what happens in edge cases. The word “Fluent” does not restrict language-related web searches in any useful way.

I worked around issue 1 with some ugly nested localisation hacks, but I plan to rip Fluent out before release. It heralds itself to be the saviour of all i18n, but it’s literally worse than the mess that came before it.

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

#68

Post by ggrrhh_ta »

jimmywetnips wrote: post #56
dale_glass wrote: post #35

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…

In this particular case, only "está" (instead of "es") is correct. Otherwise it means that the person is an active person, instead of meaning that at the present period of time, the person can be found active/online.

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

#69

Post by ggrrhh_ta »

jimmywetnips wrote: post #56
dale_glass wrote: post #35

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…

Also, in Chinese, the logogram might change depending on the gender: 他/她, he/she, also part of his/her

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

#70

Post by TheAceOfHearts »

Wildgoose wrote: post #6

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.

One common problem on macOS that International users often complaint about is how messages in their native language are really long so they get cut off, and they're never fixed despite being reported for years. But if even Apple, a multi-Billion dollar company, struggles with these problems, I'm not sure there's any easy solutions.
Post reply on HN