Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fluent 1.0: a localization system for natural-sounding translations

hacks.mozilla.org

Post reply on HN
Print view View original

71–80 of 117 posts

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

#71

Post by ajuc »

stasm wrote: post #62
ajuc wrote: post #29

Does it handle the "x of y" in Slavic languages correctly? For example in Polish: "Page 3 of 4" is "Strona 3 z 4" "Page 3 of 100" is "Strona 3 ze 100"

This is an excellent question and a very good use-case. I'm a Polish speaker myself, so I can definitely relate. It's also a good excuse for me to talk a little bit more about the advanced features of Fluent. The Fluent Syntax is a simple declarative DSL. By design, it doesn't allow translators to build complex conditionals or use arithmetic. There is, however, an escape hatch. The problem you described can be solved…

Thanks for the detailed answer.

Right now I'm using qt translation system, it handles nicely various plural forms, just like Fluent.

But it requires special code in each message that has "X of Y" to handle the "ze 100" correctly in Polish. It might be done for Polish, because we have Polish developers, but many languages have similar quirks and it's not done for them. And it would result in combinatorial explosion of translation message versions if source code had to add special case for each quirk in each language.

This seems to be a much better solution.

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

#72

Post by stasm »

Zenbit_UX wrote: post #63
stasm wrote: post #10

Earlier quoted context omitted.

(Author of the blog post here.) Great question, thanks! Unicode defines six categories of plural forms: zero, one, two, few, many, and other. The names of these categories always appear in English. Unicode also maintains a collection of all mappings of numerical rules to these categories, for all languages supported by the CLDR. See http://www.unicode.org/cldr/charts/latest/supplemental/langu... for the mapping corre…

Care to comment about how it might handle one bold word or a link mid sentence?

When Fluent formats translations, it returns simple strings (in the sense of primitive computer types). They can include markup which is parsed by a higher-level abstraction responsible for actually showing the translations somewhere in the UI. Take a look at https://github.com/projectfluent/fluent.js/wiki/DOM-Overlays in the experimental fluent-dom package, and their React equivalent, https://github.com/projectfluent/fluent.js/wiki/React-Overla....

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

#73

Post by stasm »

michaelmior wrote: post #57
madeofpalk wrote: post #34

Earlier quoted context omitted.

The problem here is tooling and workflows. Often you'll be using a SaaS product to manage translations, like Lokalise or similar products. At the end of the day, these just give you a whole bunch of strings to put in your app. I've found this really hard. At my last place we just ate the cost (and ugliness) of included HTML in this strings and dangerously inserting them into the page.

Definitely a problem. I think what will really make Fluent take off is if someone can provide good translation tools and workflow. The syntax looks great, but for most projects, I suspect it's impractical to expect translators to write Fluent manually.

Our goal was to design a simple DSL which is easy to read and make small edits to. Copying and pasting is a powerful learning method :)

We're also working on creating richer and more streamlined authoring experience in Pontoon, Mozilla's translation management system. You can read about the current state of Fluent support in Pontoon in my colleague's post at https://blog.mozilla.org/l10n/2019/04/11/implementing-fluent....

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

#74

Post by stasm »

ajuc wrote: post #71
stasm wrote: post #62

Earlier quoted context omitted.

This is an excellent question and a very good use-case. I'm a Polish speaker myself, so I can definitely relate. It's also a good excuse for me to talk a little bit more about the advanced features of Fluent. The Fluent Syntax is a simple declarative DSL. By design, it doesn't allow translators to build complex conditionals or use arithmetic. There is, however, an escape hatch. The problem you described can be solved…

Thanks for the detailed answer. Right now I'm using qt translation system, it handles nicely various plural forms, just like Fluent. But it requires special code in each message that has "X of Y" to handle the "ze 100" correctly in Polish. It might be done for Polish, because we have Polish developers, but many languages have similar quirks and it's not done for them. And it would result in combinatorial explosion of…

Thanks!

> And it would result in combinatorial explosion of translation message versions if source code had to add special case for each quirk in each language.

This is the exact problem we designed Fluent to solve. If you get a chance to try it out, feel free to reach out to me if you questions. I'll be more than happy to help and to hear feedback.

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

#75

Post by michaelmior »

stasm wrote: post #73
michaelmior wrote: post #57

Earlier quoted context omitted.

Definitely a problem. I think what will really make Fluent take off is if someone can provide good translation tools and workflow. The syntax looks great, but for most projects, I suspect it's impractical to expect translators to write Fluent manually.

Our goal was to design a simple DSL which is easy to read and make small edits to. Copying and pasting is a powerful learning method :) We're also working on creating richer and more streamlined authoring experience in Pontoon, Mozilla's translation management system. You can read about the current state of Fluent support in Pontoon in my colleague's post at https://blog.mozilla.org/l10n/2019/04/11/implementing-fluen…

Cool! That looks like a great start :) I don't really do any l10n work myself so this was really just a bystanders perspective.

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

#76

Post by aardshark »

ngrilly wrote: post #25

The comparison with gettext is really interesting: https://github.com/projectfluent/fluent/wiki/Fluent-vs-gette... Especially the advantages and drawbacks of using the source string as a message identifier, compared to a developer provided ID. I'm wondering if fluent has something similar to xgettext, to extract the IDs from the source code? Edit: Looks like there is some discussion about extraction here: https://git…

This comparison mentions that in gettext, using the source string as a message identifier "makes it impossible to introduce multiple messages with the same source string which should be translated differently."

It's rather disingenuous to say this without mentioning that in gettext, the actual identifier is a combination of the source string and the string context, which is blank by default. But the context can and should be provided in cases where disambiguation is required.

https://www.gnu.org/software/gettext/manual/html_node/Contex...

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

#77

Post by aembleton »

quelltext wrote: post #7

In the Czech example, how is it obvious that `few` stands for 2, 3, 4? Is that just how the concept of "few" (note the English term) is defined and understood by all Cezch speakers and thus this language specific meaning is encoded by Mozilla to map to the range 2-4? My point is that while there might be a concept of "few" that does map uniquely to that range, I am not sure naming the keyword "few" is the right name…

This confused me too. To take the example, I'd prefer the following:

  tabs-close-warning-multiple = {$count ->
      [2..4] Chystáte se zavřít {$count} panely. Opravdu chcete pokračovat?
     *[] Chystáte se zavřít {$count} panelů. Opravdu chcete pokračovat?
  }
Specify a range (2..4). The second option shouldn't need to match as it is the default value anyway (signified by the *)

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

#78

Post by aembleton »

sanqui wrote: post #12
quelltext wrote: post #7

In the Czech example, how is it obvious that `few` stands for 2, 3, 4? Is that just how the concept of "few" (note the English term) is defined and understood by all Cezch speakers and thus this language specific meaning is encoded by Mozilla to map to the range 2-4? My point is that while there might be a concept of "few" that does map uniquely to that range, I am not sure naming the keyword "few" is the right name…

Czech speaker here. When stating a plural in the nominative form, counts of 2-4 items always use the nominative plural and counts of 5+ items use the genitive plural. This concept is understood by Czech speakers natively and doesn't have any description. "Few" is therefore just a descriptive name chosen by the Fluent developers, and probably covers other languages with a similar concept.

Few is languages specific, so the logic for it should live with the language. Another language might have a plural for 3-6 but you would then need another way to describe it. I've mentioned this in another comment, but I think a range would be better such as 2..4 or 3..6

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

#79

Post by drdaeman »

stasm wrote: post #20
lewisl9029 wrote: post #15

One thing that I've always struggled w.r.t i18n is having to split messages up into often times less coherent chunks in order to add things like links or tooltips or styling elements in the middle of the text, which makes it more difficult to localize messages as a holistic piece independent of the source language. For a slightly contrived example to demonstrate this, let's say you have a string like this: "Please cl…

This is a great point and something that we've seen come up very often in building UIs. The good practice which we recommend to developers at Mozilla is to avoid splitting or nesting messages, because it makes it harder for translators to see the entire translation at once. We've taken a layered approach to designing Fluent: what we're announcing today is the 1.0 of the syntax and file format specification. The imple…

> `[one] 1 time *[other] {$clickCount} times`

How does this work for languages that have more complex pluralization rules?

E.g. in Russian it's "1 раз", "2 раза", "11 раз", "12 раз", "22 раза" and "55 раз" - the case depends on the number ending, with exceptions for 11, 12, 13 and 14.

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

#80

Post by lewisl9029 »

whoisthemachine wrote: post #45
lewisl9029 wrote: post #18

Earlier quoted context omitted.

More and more, I'm starting to think maybe plain text isn't always the best abstraction to be using for defining messages for i18n. If messages were to be defined in terms of whatever primitive you're using to build your UI (i.e. React components if you're using React, and raw html template nodes if you're working with plain html), then all of this impedance mismatch might disappear. In the React case, a component or…

This is an interesting approach, but it's not tooling independent. If you can rely on your translations only seeing use in React components, then it may be just what you need.

That's a great point. Although maybe one way to make the approach more generic is to treat them as functions that happen to return React Nodes as opposed to stateless functional components.

Then you could write an alternative set of functions that returns say Vue components or raw html templates.

It still doesn't make individual translations _always_ reusable across paradigms, but I'm not so sure if the impedance mismatch associated with working with raw strings in a modern UI frameworks is worth the translation portability of that de-facto approach. And at the end of the day the only transaction functions you'd have to duplicate are the ones return more than raw strings, so it's not the end of the world.

Post reply on HN