i am on a 2 year long rabbit hole to solve many i18n problems that devs face https://github.com/inlang/inlang
we are in our third (major) refactor because the problem is so complex and new requirements emerge regularly :/
Lessons From Linguistics: i18n Best Practices for Front-End Developers
41–50 of 102 posts
Re: Lessons From Linguistics: i18n Best Practices for Front-End Developers
#42Is there some kind of Auto-i18n where the function sends a request to a server if there is no localization available? The server could in turn request a translation from a service and add it to the localization files
I believe the library mentioned in the article (i18next) provides the necessary hooks to do this. See ‘saveMissing’ option [1]. Though you need a backend to save this and manage translations. The maintainer of that library, locize, business model is to provide such a service. [1] https://www.i18next.com/how-to/extracting-translations
There’s a really nice babel plugin as well that can do the extraction.
Re: Lessons From Linguistics: i18n Best Practices for Front-End Developers
#43It'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.
---
Re: Lessons From Linguistics: i18n Best Practices for Front-End Developers
#44In 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…
For what it's worth, the term "fresh water" has each of those separate connotations in American English too, and it can be just as context-dependent. Both "These fish belong in fresh water, not salt water" and "I put fresh water in the ice trays because the old stuff was stale" are valid contextually and linguistically.
Re: Lessons From Linguistics: i18n Best Practices for Front-End Developers
#45> The order of the words is hardcoded, with “added” preceding the date. This would be incorrect in many languages, from Dutch (“1 januari toegevoegd”) This is simply not true. Since English and Dutch are both Germanic languages they largely work the same way. Saying "Toegevoegd: 1 januari" would be just fine. By using "1 januari toevoegd" you're syntactically changing the sentence.
1 januari toegevoegd sounds like you're adding the date. If you're going to write it as a sentence it ought to have something like "Op 1 januari", and in that case it actually doesn't matter whether you put the toegevoegd before or after "op 1 januari". But I agree, nothing wrong with "Toegevoegd: 1 januari".
Re: Lessons From Linguistics: i18n Best Practices for Front-End Developers
#46I’m highly procedural game dev lots of text has unpredictable text inserted within it. Eg, a notification for how “(person 1) has left (room1) to perform (action) in (room2) with (item1)”
So your “never do interpolation” trick is a bit of an over-simplification already. Not to mention all the ways to modify a verb or noun with surrounding words, Eg, preceding it with the. I walked to Larry vs I walked to the couch
Our languages systems for our game got pretty complex, pretty fast, and I find these simplified hand wavy articles pretty frustrating tbh
Re: Lessons From Linguistics: i18n Best Practices for Front-End Developers
#47Earlier 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…
For what it's worth, the term "fresh water" has each of those separate connotations in American English too, and it can be just as context-dependent. Both "These fish belong in fresh water, not salt water" and "I put fresh water in the ice trays because the old stuff was stale" are valid contextually and linguistically.
Yes, but it does not necessarily have those two connotations in other languages (which is the issue here).
In Portuguese, if you want to say "fresh water" (as in, "low-salinity water"), you use the term "sweet water", rather than "fresh water" ("fresh water" can only be interpreted either as "cold water" or "non-stale water", but never as "low-salinity water").
Re: Lessons From Linguistics: i18n Best Practices for Front-End Developers
#48tangent:
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):
Re: Lessons From Linguistics: i18n Best Practices for Front-End Developers
#49I would give my little toe to see what this person's opinion is on CCS/CCMS (Component Content Systems)
https://en.wikipedia.org/wiki/Component_content_management_s...
There's quite a bit more to be written here about natural language, formal language, and how constituents of each class interact with each other. Stuff that the initial architects of "component content" were not necessarily thinking about, because they were coming at the problem from an extremely limited corpus.
Re: Lessons From Linguistics: i18n Best Practices for Front-End Developers
#50A 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…
[deleted]