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

51–60 of 117 posts

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

#51

Post by Khol »

megous wrote: post #41

Re: genedered pluralized example in the article. How will the system deal with the fact, that in some languages (Czech, too): ($count -> Jana added {n} {apples|apple}) ($gender -> to {his|her} profile) the $gender will affect what form the word "added" should take. You're suddenly dealing with possibilities($count)*possibilities($gender) variants of the sentence

I would assume that the translator could provide a translation along the lines of:

  ($count -> Jana ($gender -> {addedHis|addedHer}) {n} {apples|apple}) ($gender -> to {his|her} profile)
(obviously with addedHis and AddedHer substituted for the correct word.)

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

#52

Post by ngrilly »

stasm wrote: post #30
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…

There's a tool written by a Udacity developer which can be used to autoextract copy from React source code: https://github.com/udacity/fluent-react-utils/tree/master/pa...

I was thinking of something along this line. Thanks!

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

#53

Post by megous »

tobr wrote: post #48
megous wrote: post #41

Re: genedered pluralized example in the article. How will the system deal with the fact, that in some languages (Czech, too): ($count -> Jana added {n} {apples|apple}) ($gender -> to {his|her} profile) the $gender will affect what form the word "added" should take. You're suddenly dealing with possibilities($count)*possibilities($gender) variants of the sentence

Wouldn’t you just wrap that word in another selector?

Will the system still be sanely usable for translators?

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

#55

Post by Tomte »

arnsholt wrote: post #31
Tomte wrote: post #9

Earlier quoted context omitted.

Great article! I'm always impressed by the thought going into Perl libraries. There was a presentation years ago, how Perl handled Unicode right and every other programming language didn't (with Python 3 pretty close, IIRC). Does anyone remember the URL?

I think the presentation you're thinking of is Tom Christiansen's Unicode: The Good, the Bad, and the (mostly) Ugly : https://www.azabani.com/pages/gbu/

I think that's the one. Thank you!

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

#56

Post by lifthrasiir »

ajuc wrote: post #47
lifthrasiir wrote: post #42

Earlier quoted context omitted.

As far as I can tell Fluent has no builtin support for tagging a phonemic information to messages or arguments (it only supports plural rules and number formatting largely derived from the CLDR). You can probably specify special cases with selectors (but it will quickly go absurd, for Polish I guess that applies to 6, 7, 16, 17, 60..79, 100..199, 600..699 and so on?) or have an external function. Context: Polish prep…

Funnily enough "Strona 3 z 6" and "Strona 3 z 7" sounds correct but "Strona 3 z 100" doesn't. So I think it's only words starting with "s", not "sz" nor "si". And only 0 starts with "z" so it's not a problem (you never have "X out of 0"). So the only special case is for 100-199, 100 000-199 999, etc.

Yeah, it is clear that I don't speak Polish ;-) What is a common workaround there? "Strona X z(e) Y"?

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

#57

Post by michaelmior »

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.

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.

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

#58

Post by ngrilly »

olau wrote: post #50
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…

Don't take the comparison at its face value, it's clear to me that whoever wrote it isn't really familiar with gettext, or deliberately talking it down. Yes, it's sort of ancient, but the problems mentioned can be solved. And using the source string as ID is a pretty clever trick. Of course, there are some downsides, but there are certainly also downsides with separate IDs. Having said that, Fluent looks interesting.

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 ;-)

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

#59

Post by ajuc »

lifthrasiir wrote: post #56
ajuc wrote: post #47

Earlier quoted context omitted.

Funnily enough "Strona 3 z 6" and "Strona 3 z 7" sounds correct but "Strona 3 z 100" doesn't. So I think it's only words starting with "s", not "sz" nor "si". And only 0 starts with "z" so it's not a problem (you never have "X out of 0"). So the only special case is for 100-199, 100 000-199 999, etc.

Yeah, it is clear that I don't speak Polish ;-) What is a common workaround there? "Strona X z(e) Y"?

> What is a common workaround there?

Ignoring the issue altogether :) Or, if you're pedantic - implementing the special cases in the source code. But that's unmaintenable if you have lots of languages.

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

#60

Post by Zenbit_UX »

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 how I handle those cases in vue:

clickHere: { one: 'Please' two: { singular: ' click here {0} time ', plural: ' click here {0} times ' }, three: 'to continue', link: 'google.com/en/' }

{{ this.$i18n('clickHere.one') }} {{ this.count > 1 ? this.$i18n('clickHere.two.plural', this.count) }} : this.$i18n('clickHere.two.singular', this.count) }} {{ this.$i18n('clickHere.three') }}

Don't forget to localize your links! English might not need it but many languages eventually will point to a different url.

Post reply on HN