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

41–50 of 117 posts

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

#41

Post by megous »

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

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

#42

Post by lifthrasiir »

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"

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 preposition "z(e)" is spelled "z" if the following word starts with s and z and alikes (problematically enough, the exact rule is not systematic) and "ze" otherwise. Korean has a similar case with postpositions "은(는)" and "이(가)" where the former is for words ending with a consonant and the latter is for words ending with a vowel, and the ko-KR localization of Firefox seems to completely ignore and/or sidestep this; the last letter is assumed (e.g. "{-brand-name}는") or a static word is inserted (e.g. "{$user} 사용자는" instead of "{$user}은(는)").

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

#43

Post by Khol »

cpfohl wrote: post #39
Khol wrote: post #19

Earlier quoted context omitted.

Think about how often the english documentation coming with cheap products from china is mocked - do you really want your professional output to be treated in the same regard?

No, but if it comes down to writing better translation code, or adding features and bug fixes, I know where my clients typically land.

If you're writing translation code then you're (probably) doing it wrong.

If your clients are happy to only ever have a product in one language which will never have to deal with anything outside the 7bit ascii range then ignoring the complexity required to do it is (probably) fine.

As soon as you hit some requirement which violates the above if you haven't considered how this might affect you you're likely in for some horrible problems when suddenly you need to handle these things.

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

#44

Post by pluma »

ktpsns wrote: 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.

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

#45

Post by whoisthemachine »

lewisl9029 wrote: post #18
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…

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.

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

#46

Post by pluma »

progx wrote: post #35

Hope someday somebody invent .pot files, plurals and gettext.

No need to be sarcastic. The documentation explains the advantages over gettext.

Most notable being that using the source language string as identifier a) discourages changes (and improvements) to the source language strings and b) makes it hard to handle strings that appear the same in the source language but need different translations.

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

#47

Post by ajuc »

lifthrasiir wrote: post #42
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"

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.

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

#48

Post by tobr »

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?

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

#49

Post by wccrawford »

pcr910303 wrote: post #2

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 :-(

I'm an English native speaker that dabbles in other languages occasionally, and I know enough to recognize possible problem areas, but not enough to actually do anything about them.

The complexity of this Fluent library shows what a massive problem it is. I'm not surprised that we continue to be this bad at it.

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

#50

Post by olau »

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.

Post reply on HN