81–90 of 102 posts
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.
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…
Earlier quoted context omitted.
Yes, but don’t you think it might be little more diplomatic to say something like: > 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,…
I don't know, I personally value directness more than a "compliment sandwich". And I don't consider criticism of code to be criticism of one's person or expertise. It may be a cultural thing (I'm German). But you'll have to take that up with the person you originally replied to.
When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."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…
Alice is online -> Alice on verkossa
Mail to Alice -> Postita Alicelle
And no, you can't use "%s"+ "lle" either, it depends on name:
Mail to John -> Postita Johnille
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…
I think most common languages you can either choose between a combo adjective like 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…
I do the opposite.
Instead of training my users to accept a kludge, I take the time to make it correct, even if it's hard.
I have the luxury of full-time professional translators on staff, and I know that not everyone else does.
But I've always believed that computers are supposed to work for people, not the other way around.
Earlier quoted context omitted.
Good news is folks are working on better tooling, for example fluent[0] by mozilla. The bad news though is adoption. --- 0: https://projectfluent.org/
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…
> 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 opposite.
> 3) The input files mandate a weird arrangement of new lines for even the simplest branching
Same as above.
> 4) The documentation is too Spartan to know what happens in edge cases.
We're a small team :)
> It heralds itself to be the saviour of all i18n, but it’s literally worse than the mess that came before it.
I'm sorry to hear it doesn't work for you. I'm relieved that your criticism is seems more subjective except of one missing feature that no other l10n system has as of yet. We'll keep pushing, but if you encounter a better l10n system, please let me know! We're working on Unicode MessageFormat 2.0 based on Fluent and incorporating lessons learned.
Earlier quoted context omitted.
> 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 ...").
Yes, but don’t you think it might be little more diplomatic to say something like: > 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,…
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…
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.
Earlier quoted context omitted.
Yes, but don’t you think it might be little more diplomatic to say something like: > 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,…
[flagged]
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 presence on the Internet, and don't hide behind anonymity. It helps me to stay honest and respectful.
During my career, I worked with hundreds of people that put my experience and technical prowess to shame.
There really are a lot of us around here, but we aren't interested in playing status games.
This is exactly what I mean.