91–100 of 102 posts
Can I just rant for a second about how much I hate the whole ` ` trend that folks seem to love? This intentional sort of obfuscation makes it hard for juniors or students (the exact people who would be interested in an article like this), to engage in the material. The most egregious example is doing it for the word 'accessibility'!
Also known as for short.
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…
Using a word that's longer than three characters like "identity" will help ensure that it won't conflict with a real locale.
Smells: * 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 wha…
> If you're concatenating sentence bits, you're doing it wrong. This is completely impractical for anything other than the most static content. Take the most basic line from any single imagined game. E.g. “Your [Abrams tank] has [fired] a [lead-tipped bullet] at a [green] [dragon].” Ok, let’s say you have fifteen unit types, five attack types, thirteen types of ammo, thirty enemy type adjectives, and fifty enemy noun…
Also am not talking about this as an absolute moral-ethical challenge. In the examples I gave, it's usually less work long term on the developer to do the right thing, and a more efficient use of translation budget because you're not spending money to get convoluted translations that sound confusing or don't sound idiomatic. Why bother translating if your users are going to use English anyways?
Smells: * 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 wha…
> 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. Even the very big ones get this wrong. I believe AliExpress still uses the sa…
Earlier quoted context omitted.
[flagged]
Why should I, when you're making it clear that you're only interested in using it as an attack vector? You have no interest at all in my experience, and that is clear, from your combative and insulting approach. BTW: They are not "wild claims," as, literally, five minutes, browsing my extensive online presence, will show (try following one of the links I provided, just for a start). I have an open and aboveboard pres…
Earlier quoted context omitted.
Fluent is terrible. I excitedly implemented it in my most recent app, and immediately ran into so many issues. 1) It can transclude variables in translation strings, but these variables cannot themselves be localised. This makes Fluent completely useless for constructions like “Your knight has killed a dragon with a crossbow” in any language with case or gender, unless you pre-translate every possible combination in…
Hi! Thank you for your critique! > 1) “Your knight has killed a dragon with a crossbow” We have a proposal for dynamic references to address this problem - https://github.com/projectfluent/fluent/issues/80 - it's non-trivial but I hope we'll see it solved in Fluent and/or in MessageFormat 2. > 2) The parser is extremely sensitive True. It's on purpose. We wanted to start with strict and loosen, rather than the opposi…
The first feature is not optional - it has been a feature of i18n systems since the 1990s, possibly earlier. I’ve seen cludged-together in-house solutions that can do it without breaking a sweat. It is currently not feasible to use Fluent to localise any substantive, dynamic content in languages with case or gender - which is the main challenge an i18n package exists to solve. (I note the issue you link is five years old, dismisses the problem as not significant, and flat out states it is not being worked on.)
Translation files are generally made by translators, not programmers, and the fact that Fluent falls over in a slight breeze makes it difficult to imagine a translator being able to produce working Fluent files. This is not a ”subjective” problem. Translators do not, and should not, work for free. Using Fluent adds considerable (and needless!) complexity and therefore expense.
As you point out, you’re working on a new data format, so it’s unclear why anyone should adopt (and pay for translations in) the current moribund format.
I genuinely do wish you guys the best, and I apologise if I spoke too bluntly above, but it is not merely a matter of personal opinion that Fluent is de facto still in alpha.
Smells: * 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 wha…
> If you're concatenating sentence bits, you're doing it wrong. This is completely impractical for anything other than the most static content. Take the most basic line from any single imagined game. E.g. “Your [Abrams tank] has [fired] a [lead-tipped bullet] at a [green] [dragon].” Ok, let’s say you have fifteen unit types, five attack types, thirteen types of ammo, thirty enemy type adjectives, and fifty enemy noun…
Analysing “green house” as either “green”.concat(“ house”) or “{} {}”(green, house) is not meaningfully different, and runs into the same i18n problem (the order should be reversed for many languages, like Spanish and French).
Earlier quoted context omitted.
> If you're concatenating sentence bits, you're doing it wrong. This is completely impractical for anything other than the most static content. Take the most basic line from any single imagined game. E.g. “Your [Abrams tank] has [fired] a [lead-tipped bullet] at a [green] [dragon].” Ok, let’s say you have fifteen unit types, five attack types, thirteen types of ammo, thirty enemy type adjectives, and fifty enemy noun…
As others have said, I was talking about concatenation as opposed to interpolation. Interpolation still has challenges. It's hard to make arbitrary sentences with many placeholders work with agreement. But concatenation is almost always a bad choice. Also am not talking about this as an absolute moral-ethical challenge. In the examples I gave, it's usually less work long term on the developer to do the right thing, a…
I find myself frustrated by devs perpetually talking about localisation as an impossible, semi-mystical 'gotchya' that causes untold cultural offence if mishandled, and I took that frustration out on your comment, and I apologise.
I agree that keeping localisation in mind early is better than remembering about it too late.
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 yo…
Seamlessly embedding user-generated content into template text is a losing battle. There are always going to be users who test the waters with emojis, zalgo text, l33tspeak profanity, SQL/XSS injection attempts, copypastas, and so on. In the face of such merry nonsense, linguistic idiosyncrasies like proper gendered forms are moot concerns.
Don't forget Right-To-Left languages, that also affects how UI elements are arranged (position within the page) and rendered (input widgets like sliders get reversed).
I think the currently blessed CSS solution is to only use {inline,block}-{start,end} https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_logical... in place of {left,right,top,bottom} which then automagically supports even vertical scripts like Traditional Mongolian, but most people probably don't think that far ahead when just starting out.
Vertical Japanese is very common in the print magazines I read, and is RTL amongst the rest of the Japanese text which is LTR. I just don't see it much online because of the trouble of setting it.
If I ever have too much spare time I must try to support vertical Mongolian in my app.