Earlier quoted context omitted.
The downside of using separate IDs is that the developer has to "name" each string shown in the user interface, instead of just using the source string as an ID. And as you know, naming things is hard ;-)
Yes, naming is hard, but, to quote the previous commenter "this can be worked around" - you can `slug` any string if you want to. We prefer to think of the ID as the base of the social contract between the dev and the localizer. This enables a lot of fine tuned control over string invalidation.
Fluent 1.0: a localization system for natural-sounding translations
91–100 of 117 posts
Re: Fluent 1.0: a localization system for natural-sounding translations
#92Earlier quoted context omitted.
GNU gettext is a well working framework for i18n. For the sentence ordering we include all variables in the translations, but split translations on styles. We then give the translator the text in order of html appearance in source code for context. Translators can then rearrange everything but the variable across the string and also leave stuff blank when necessary. It's not perfect, but works in most cases. And in t…
Hi! We've been working with and evaluating Gettext when we started Fluent. Our opinion is similar to Unicode's - Gettext is fundamentally flawed design for internationalization purposes. Here's you can find more detailed explanation of our position - https://github.com/projectfluent/fluent/wiki/Fluent-vs-gette... Please, don't take it as a criticism of using it. We just don't think it scales and we don't think it's p…
Did the Unicode consortium express critics about gettext? Could you provide some reference about this?
Re: Fluent 1.0: a localization system for natural-sounding translations
#93Earlier quoted context omitted.
Hi! We've been working with and evaluating Gettext when we started Fluent. Our opinion is similar to Unicode's - Gettext is fundamentally flawed design for internationalization purposes. Here's you can find more detailed explanation of our position - https://github.com/projectfluent/fluent/wiki/Fluent-vs-gette... Please, don't take it as a criticism of using it. We just don't think it scales and we don't think it's p…
> Our opinion is similar to Unicode's - Gettext is fundamentally flawed design for internationalization purposes. Did the Unicode consortium express critics about gettext? Could you provide some reference about this?
I can also point out to ICU MessageFormat - which has been designed much after Gettext and, I'd dare to say on purpose, bares no resemblance to it.
Re: Fluent 1.0: a localization system for natural-sounding translations
#94Earlier quoted context omitted.
> Our opinion is similar to Unicode's - Gettext is fundamentally flawed design for internationalization purposes. Did the Unicode consortium express critics about gettext? Could you provide some reference about this?
I don't know if there's any public statement about this. I base my position on experience at Unicode Conference and work on CLDR and ICU. I understand that it diminishes the value of my claim. I can also point out to ICU MessageFormat - which has been designed much after Gettext and, I'd dare to say on purpose, bares no resemblance to it.
Re: Fluent 1.0: a localization system for natural-sounding translations
#95Earlier quoted context omitted.
> Our opinion is similar to Unicode's - Gettext is fundamentally flawed design for internationalization purposes. Did the Unicode consortium express critics about gettext? Could you provide some reference about this?
I don't know if there's any public statement about this. I base my position on experience at Unicode Conference and work on CLDR and ICU. I understand that it diminishes the value of my claim. I can also point out to ICU MessageFormat - which has been designed much after Gettext and, I'd dare to say on purpose, bares no resemblance to it.
Re: Fluent 1.0: a localization system for natural-sounding translations
#96Earlier quoted context omitted.
The rules for cardinal numbers in Slavic languages are quite complex. "few" is not just 2, 3, 4, but any number less than 100 ending in 2, 3, 4. You have to use a function to handle the situation. "few" is basically the function name, which is as good as any.
It's not "less than 100 ending in 2, 3, 4". It's "2, 3, or 4 mod 10, but not 12, 13, 14 mod 100". So for example "1002" is "few" in this sense (even though it's bigger than 100) but "14" is not, even though it's less than 100 and ends in 4.
Re: Fluent 1.0: a localization system for natural-sounding translations
#97OMG this is so cool to a person who lives in the CJK world (to be specific, I’m Korean) where the order of noun/verb/adj is reversed and always gets to see programs that display text something like ‘Site is news reader HN’, ‘Button press confirm to’. It’s a pity that the programming world is still super bad at i18n :-(
Re: Fluent 1.0: a localization system for natural-sounding translations
#98OMG this is so cool to a person who lives in the CJK world (to be specific, I’m Korean) where the order of noun/verb/adj is reversed and always gets to see programs that display text something like ‘Site is news reader HN’, ‘Button press confirm to’. It’s a pity that the programming world is still super bad at i18n :-(
It won't help much with Chinese localization, where the persistent problem is that developers assume every language has the words "yes" and "no".
Re: Fluent 1.0: a localization system for natural-sounding translations
#99Isn't it amazing that even with these "apparently solved and very basic" problems like i18n, there are still so many low-hanging fruits, and an open source project can do better than many companies. I'm German and I disabled spell checking almost everywhere, because most implementations are extremely poor in German. Word lists are a poor solution to capture different word forms, and I find it surprising that even in…
I guess my biggest pet peeve with German spellcheckers and autocomplete solutions other than the nonexistent support for compound words is that most of them don't understand capitalisation rules.
Re: Fluent 1.0: a localization system for natural-sounding translations
#100OMG this is so cool to a person who lives in the CJK world (to be specific, I’m Korean) where the order of noun/verb/adj is reversed and always gets to see programs that display text something like ‘Site is news reader HN’, ‘Button press confirm to’. It’s a pity that the programming world is still super bad at i18n :-(
It won't help much with Chinese localization, where the persistent problem is that developers assume every language has the words "yes" and "no".