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
Lessons From Linguistics: i18n Best Practices for Front-End Developers
51–60 of 102 posts
Re: Lessons From Linguistics: i18n Best Practices for Front-End Developers
#52In 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…
Re: Lessons From Linguistics: i18n Best Practices for Front-End Developers
#53Earlier 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…
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* 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
#55This 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
#56A 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…
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
#57Earlier 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…
Re: Lessons From Linguistics: i18n Best Practices for Front-End Developers
#58A 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…
Re: Lessons From Linguistics: i18n Best Practices for Front-End Developers
#59Earlier 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 ...").
> 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
#60Earlier 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]