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

111–117 of 117 posts

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

#111

Post by Sylos »

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…

From an accessibility point of view, it's also recommended to avoid links that only span over such half-sentences.

Screen reader users will often navigate your page by cycling through the links that are on the page and then they'll get only the link-text read out, not the surrounding text.

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

#112

Post by pas »

madeofpalk wrote: post #34
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…

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.

That's always a problem, even with templates. Angular does sanitization. Which is of course not ideal from a runtime performance point, but they probably weighted the cost-benefit and found it to be an okay trade-off.

Though if the i18n string files are present at build time, then this sanitization step could be done there.

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

#113

Post by stasm »

indentit wrote: post #106

it'd be great to see syntax highlighting for FTL files in the popular text editors, but I guess they would have to be unofficial unless a member of Mozilla/Fluent team wants to maintain it...

You can get decent highlighting for basic Fluent messages by setting the editor to a mode for Properties files. For instance, whenever I type Fluent examples in GitHub, I use the following markdown:

    ```properties
    # A comment
    hello = Hello, world!
    ```
This is in fact by design. Properties files are quite nice for simple things. Fluent builds on top of them, and provides modern features like multiline text blocks (as long as it's indented, it's considered text continuation) and the micro-syntax for expressions: {$var}, {$var -> ...} etc.

So far, I haven't had much time to invest in building proper highlighting modes for popular editors. There are ACE and Vim modes mentioned in other comments here, and also a slightly outdated https://atom.io/packages/language-ftl20n written by a contributor. I'd love to see more such contributions, and I'll be more than happy to help by reviewing code!

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

#114

Post by stasm »

aembleton wrote: post #77
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 *)

The (2..4) range would work for Czech in this example (if I'm reading the CLDR right), but I'm afraid it wouldn't be sufficient for languages with more complex plural rules. Take the rule that returns "one" in Latvian, for example:

    n % 10 = 1 and
      n % 100 != 11 or
    v = 2 and
      f % 10 = 1 and
      f % 100 != 11 or
    v != 2 and
      f % 10 = 1
…where n is the absolute value of the number, f is the visible fractional digits with trailing zeros, and v is _the number_ of visible fraction digits with trailing zeros. Some rules can get even more complex than that; see [0] and [1].

It's safer and more robust to rely on the plural categories defined by the Unicode: (zero | one | two | few | many | other), and by the APIs provided by the platform (ICU, Intl.PluralRules, etc.).

[0] http://www.unicode.org/cldr/charts/latest/supplemental/langu...

[1] http://unicode.org/reports/tr35/tr35-numbers.html#Operands

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

#115

Post by stasm »

aembleton wrote: post #77
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 *)

> The second option shouldn't need to match as it is the default value anyway (signified by the *)

That's an interesting suggestion! Right now, the identifier between the brackets is required, but we could relax this in the future. In 1.0, we erred on the side of more conservative and explicit design, to improve the readability and discoverability of the syntax for translators.

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

#116

Post by cbenz »

Vinnl wrote: post #65
Andrex wrote: post #61

Earlier quoted context omitted.

Why fluent-react and not (in addition to) fluent-web-components? :(

One advantage I can imagine is that you can prerender the React components, outputting e.g. plain HTML. With tools like e.g. React Static, that means you can somewhat ergonomically generate different static websites for different languages, avoiding the runtime costs of looking up the correct strings.

Using the Svelte JS library (https://svelte.technology) you can have both: server-side rendered components [1] and compile to web components (custom elements) [2]

Another advantage is that the components compile to vanilla JavaScript, so we don't rely on a runtime library to run the application.

[1] https://svelte.technology/guide#server-side-rendering

[2] https://svelte.technology/guide#custom-elements

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

#117

Post by ascar »

zbraniecki wrote: post #102
ascar wrote: post #101

Earlier quoted context omitted.

You make a lot of good points in the linked article, but you lose some credibility right from the start > Secondly, it makes it impossible to introduce multiple messages with the same source string which should be translated differently. This is false. The gettext message format uses msgctxt to deal with this. It's a fundamental part of the format. The unique identifier is the combination of msgctxt and the singular…

> but you lose some credibility right from the start Thank you for the feedback! I updated the article to include the mention about `msgctxt`. Personally, in my experience, many project environments end up with partial support for this feature (for example many react/angular extractors don't support it) which leads to limited use and requires the localizer to request adding a context by the developer. I did not inclu…

Yes, I agree. It only solves a subset of the problems. Formatting and RTL/LTR is difficult to solve with gettext.
Post reply on HN