Live data from Hacker News

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

shopify.engineering

21–30 of 102 posts

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

#21
Good article. Knowing some Slavic, Latin or Asian language helps immensely when dealing with i18n.

I wrote an article on a similar subject (with some additional technical details about Android and iOS) a few years ago, with a few similar conclusions:

https://jakub.gieryluk.net/blog/reusing-software-translation...

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

#22

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.

Non-latin fonts also have different glyph widths. For example cyryllic text might be same "length" but glyphs in a system font might be wider hence overall the string needs more space.

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

#23
post #13

This is a good article, though as someone who prefers references/tables to prose for technical topics, the real find for me was the link out to the Unicode CLDR project (which sadly contains a LOT of broken links right now due to a data migration effort but I'll bookmark it & hopefully it'll be navigable in future). As someone with a Polish partner, who also fluently speaks my own weird minority local language (Irish…

The CLDR plural rules for Irish are here https://www.unicode.org/cldr/charts/42/supplemental/language... Not quite as complex as the ones for Breton https://www.unicode.org/cldr/charts/42/supplemental/language... but of course they might be wrong.

Both of these only cover case changes for the object being counted: cases are pretty common across non-English languages so this is simple enough on its own.

The main difference I see in Breton is the rules for 1-9 follow through for double-digits n1-n9 - I would've suspected this to be true for Irish but I just speak it, don't study it, so confidence in my grammatical knowledge is low.

Irish definitely doesn't have the exceptions for 71-79 & 91-99; this smells like French influence.

The main thing missing from both of these though is modifications to the actual words for numerals: they kind of get away with it by sticking to digits, but I'm not sure if that's always the case in the translated output of i18n libraries referencing this. If they're ever outputting words in place of numerical digits then these are both very incomplete.

Irish then also has an entirely different way of counting persons which isn't included.

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

#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 interpolation and declinations. Portuguese genders almost every subject in a phrase construction.

The web is killing (or creating artificial versions) of many languages because the lack of tooling...

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

#25

This is a good article, though as someone who prefers references/tables to prose for technical topics, the real find for me was the link out to the Unicode CLDR project (which sadly contains a LOT of broken links right now due to a data migration effort but I'll bookmark it & hopefully it'll be navigable in future). As someone with a Polish partner, who also fluently speaks my own weird minority local language (Irish…

Remarkable in similar situation, Irish + Polish learnt because of wife and extended family. Found when it comes i18n with the present codebase, I have inherited, it needs a lot of work, but it was immensely helpful to have two backgrounds in particular tricky languages, relative to English.

In quickly scoping out what needs to be worked, and where the inherited setup clearly falls short. Don't think knowing a great deal about other languages is necessary though for the same effect, just enough to smell something might be a bit trickier, like know say the case system in X language shows up in different ways, verb + pronoun order is not predefined.

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

#26

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…

i18next has that covered, as well as all the other issues mentioned: https://www.i18next.com/translation-function/context

(note that I don't fully understand gendered languages, the above may or may not be applicable)

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

#27

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.

While developing, it's a good practice to have at least "lorem ipsum" or auto translated versions of the phrases in your product, if you're targeting multiple languages.

Likewise though, character based languages like Chinese CAN be a lot more compact than English. But counterpoint, those same languages have a different internet culture where they will put more information in headlines. Random website I looked up; https://cn.chinadaily.com.cn/ has a small header in a sidebar:

    数读中国 | 韧性强活力足信心稳 外贸外资稳中提质
But it translates to something that's three times as long in English:

    Data Reading China | Resilience is strong, vitality is sufficient, confidence is stable, foreign trade and foreign investment are stable and quality is improving
Another thing to keep in mind for development: right-to-left languages like Arabic, Hebrew, Persian, Urdu, Kashmiri, Pashto, Uighur, Sorani Kurdish, Punjabi, and Sindhi. I was lucky to be involved in a very international website that also had a Hebrew version, the CSS developers (another luck, we had dedicated CSS developers) even made the site layout right-to-left on RTL languages.

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

#28

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/blog/pseudo-localization.

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

#29

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.
    

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

#30

  I name them by component.context.phrase

  There's https://cldr.unicode.org/index .

  In Angular I liked Transloco [0] very much.
  For Vue I use vue-i18n, I don't think there's any alternative.
  For Go I like go-i18n [1] when doing SSR Go.
  For Svelte.. not sure if there's a best package.

  [0] https://github.com/ngneat/transloco
  [1] https://github.com/nicksnyder/go-i18n
Post reply on HN