Live data from Hacker News

Fluent 1.0: a localization system for natural-sounding translations

hacks.mozilla.org

91–100 of 117 posts

Re: Fluent 1.0: a localization system for natural-sounding translations

#91
post #58

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.

Considering the translation ID as a "slug" is a good tip to ease choosing the ID. Thanks!

Re: Fluent 1.0: a localization system for natural-sounding translations

#92
post #28

Earlier 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…

> 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?

Re: Fluent 1.0: a localization system for natural-sounding translations

#93
post #92

Earlier 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 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

#94
post #92

Earlier 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.

I agree that CLDR plural forms and ICU MessageFormat are somehow an implicit critic of gettext design :-)

Re: Fluent 1.0: a localization system for natural-sounding translations

#95
post #92

Earlier 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.

Hahaha, thank you! I still feel ashamed of making a strong claim based on informal conversations, but I feel a bit vindicated by your agreement! :)

Re: Fluent 1.0: a localization system for natural-sounding translations

#96

Earlier 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.

You're right. I forgot about the teens. I don't know about Czech, but in Polish the nominative plural isn't used for numbers higher than 100. "1024 bajtów" and not "1024 bajty". If I remember the rules correctly.

Re: Fluent 1.0: a localization system for natural-sounding translations

#97

OMG 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

#98

OMG 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".

Doesn't Chinese have understandable localizations for affirmative/negative responses like "是" and "没有"? I don't see the problem.

Re: Fluent 1.0: a localization system for natural-sounding translations

#99
post #44
post #16

Isn'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.

Not just spellcheckers, virtual keyboards too. Writing German on a smartphone can be slightly infuriating

Re: Fluent 1.0: a localization system for natural-sounding translations

#100

OMG 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".

Hi! This is also a problem in Welsh [0]. In the Fluent world we solve that on the level of design principles (do not reuse the string `yes` because it can be translated to a different `yes` in different buttons) and bindings (compound messages allow us to localize a whole widget with a main message and its yes/no options).

[0] http://psychopixi.com/languages/yes-and-no/

Post reply on HN