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...
21–30 of 102 posts
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...
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.
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.
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.
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...
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…
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.
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…
(note that I don't fully understand gendered languages, the above may or may not be applicable)
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.
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.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.
I did a quick web search, and it appears to be a well-understood practice, even covered in a different Shopify blog:
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
Hello {{name}}, you have {{count}} unread message. Go to messages.
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