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

31–40 of 102 posts

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

#31

Post by worklaptopacct »

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 been replaced". The translations in Cities: Skylines use the literal translation and this has always irked me; if the translator accepted "plumbing" as a context, it would have produced a correct translation.

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

#32

Post by atoav »

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…

For special terminology an invaluable trick is to search for the wikipedia article in your language and switch the language if possible. Of course this has to be used with caution, but it can help you find the right variant of a word.

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

#33

Post by Etheryte »

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…

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 wouldn't occur in their native language.

[0] https://www.gnu.org/software/gettext/manual/gettext.html#Con...

[1] https://formatjs.io/docs/intl/#message-descriptor

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

#35

Post by dale_glass »

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 you refer to: "You're holding a dagger". Now you need to have a serious discussion with your translators, because this is going to get all kinds of tricky, as the maker of Obra Dinn discovered: https://www.youtube.com/watch?v=OMi6xgdSbMA

And to make things extra-tricky, allow users to create content. "Alice gave you a banana", where "banana" is a custom object Alice made herself.

Most translation efforts seem to give up at this point and resort to something stilted like "Alice: online"

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

#36

Post by h1fra »

Translation/Internationalisation is one of the hardest problem that is not going to be solved by technology only.

RTL, plural depending on the number, non-latin char behavior, font issues, UI broken by longer translation, context dependent translation, etc. Every time I start a project or think about it I'm sweating.

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

#37

Post by draw_down »

h1fra wrote: post #36

Translation/Internationalisation is one of the hardest problem that is not going to be solved by technology only. RTL, plural depending on the number, non-latin char behavior, font issues, UI broken by longer translation, context dependent translation, etc. Every time I start a project or think about it I'm sweating.

I don’t see any real way to deal with it except overstaffing (not gonna happen), designing everything into discrete horizontal lines, or simply coming to terms with the idea that some locales will break more than others, depending on who you are and who your customer base is. And deciding what you’re gonna do about that when it arises.

Buttons are gonna look jacked up in German because all their words are 45 letters long. RTL plays havoc with the layout. Referring to Taiwan the wrong way is a Defcon 2 political crisis. And on and on and on, it never fucking ends.

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

#38

Post by ChrisMarshallNY »

trinix912 wrote: post #18
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…

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 (including RTL and up/down). Pretty much everything I write is localized up the yin-yang. Even my test harnesses are usually localized, as I like to keep the habit of writing localized software. I've written systems that have been adopted worldwide, in many different languages, and are still in use (and expanding), many, many years later.

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

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

#39

Post by thanatropism »

Cthulhu_ wrote: post #29
dheerajvs wrote: post #4

With formatjs [0], you don't have to split the sentence for interpolation. The same example as in the article can be implemented as: const message = defineMessage({ defaultMessage: 'Learn more about supported images .', description: 'Footer text containing a hyperlink', }) and the anchor element can be interpolated as: formatMessage(message, { a: (chunks: ReactNode) => {chunks} , }) [0]: https://formatjs.io

My weapon of choice is i18next, which elegantly handles inline markup, even nested translations really well (although this example has less than ideal keys) Hello {{name}} , you have {{count}} unread message. Go to messages .

My biggest issue with i18n is not the grammar. It's the sheer uncanny valley of it.

There are translations to "Hello" in Portuguese but I'd cringe at being greeted with them by a webmail client instead of the more formal Good Morning/Afternoon.

The formal/informal gradient is very culture-bound and even hard to pin to a scalar space of possibilities. In a work environment people will fluently code-switch too -- say, between ranks or in the middle of a tiresome meeting when everyone takes five minutes to kick back and comment on lighter matters. It's hard to situate a computer in this social context.

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

#40

Post by samuelstros »

h1fra wrote: post #36

Translation/Internationalisation is one of the hardest problem that is not going to be solved by technology only. RTL, plural depending on the number, non-latin char behavior, font issues, UI broken by longer translation, context dependent translation, etc. Every time I start a project or think about it I'm sweating.

well, at least we are trying to solve i18n with tech https://github.com/inlang/inlang :D
Post reply on HN