Hi, 2013/5/10 Graydon Hoare <gray...@mozilla.com>
> > - Any expression of that conditional logic is going to be ugly, > but it is actually required for the translator to give an > accurate translation. > I agree. And if expressions are in Rust, you get the benefit of a Rust compiler validating them. A lambda must produce _some_ string to be valid; match clauses will be checked for correct type and coverage. Dynamically interpreted syntax engines do not usually give this benefit and may in fact let the translator unwittingly and quietly introduce runtime errors, which are less likely to be caught the farther off the beaten track the language is (I may be bitter at my EU-market Samsung TV, that has the Russian language option for the UI, but starts crashing randomly if you switch to it; no grudge against the Samsung folks on this list). - The odds are that not all those values will be runtime-variable; > the parts that aren't can be directly translated. The switching > is _just_ to defer a decision to runtime based on the provided > substitution value. > > - The important part: you can't ask a translator to express this > "as rust code" because the _locale_ is also a runtime setting; > that is, the translation string is evaluated at runtime > based on whatever-gettext()-returns. The programmer cannot > accommodate the translator's switch-logic because it is neither > static (locale varies at runtime) nor will be it be the same > between locales (logical structure varies with locale). > A translation catalog for a particular locale is supposed to be invoked in that locale, isn't it? But there is a thing, indeed: a translator can get "adventurous" and use more Rust than they are supposed to, up to tweaking with the locale settings (which, if the Rust runtime is any good, should only affect the internal task invoking the translation lambda). This could be solved by compiling the translation catalogs without the prelude and warning on any unusual use statements (e.g. anything outside tr:: utilities, which provide all the selector utilities a translator might need), or auto-providing a "translation prelude" and banning use altogether. That assumes you're talking about a runtime-provided noun being slotted > into a runtime-provided format string. It's of course possible this > could happen, but it's a bit of a corner case within corner cases. The > case I think the gender-selectors are designed for are those where > you're presenting a runtime-variable _person_ in a message (eg. an email > program or such). And you can pass their gender (assuming they want to > use one of the gender-binary words for it) as a value directly to the > formatter. > > A seemingly-good and short-ish slide deck on this is available here. I > recommend reading it: > > > https://docs.google.com/presentation/d/1ZyN8-0VXmod5hbHveq-M1AeQ61Ga3BmVuahZjbmbBxo/pub?start=false&loop=false&delayms=3000#slide=id.g1bc43a82_2_14 > > Especially the "non-goals". There's a limit. They just want to hit the > majority of cases. "Handle gender - at least for people". > My favorite real world example is "%s has joined the chat room." The gender may be unknown (they didn't say in their user profile), female, male, and if you are really thorough and provide for non-human chat participants, neutral. > It seems to me that given the extraordinary complexity that is lurking > here: > > > > - either you end up with a complicated micro-syntax that you'll have to > > keep buffing up as you discover corner cases in various languages and > > translators keep complaining they cannot do their job. > > I think you're overstating it. This is a problem people have been > struggling with for a long time, but have worked their way towards a > _reasonable_ solution that isn't impossibly complex. There's a > simplified implementation of it here: > > https://github.com/SlexAxton/messageformat.js > This syntax do not appear to me more "translator-friendly" than a restricted and macro-assisted use of Rust. > > - or you just decouple formatting from translation, and provide a > > separate library for translation (outside of core, most probably) > > Layering it might work. I'm not opposed to that. I just thought it worth > looking over the problem space and considering whether it's "too hard" > to support localization from the get-go, and/or whether there'd be any > advantage to combining the design of the two parts. It's pretty > important. We're going to want to localize rustc, and most other things > we write in rust. > I support a separate layer and a macro distinct from fmt!() to invoke it. Plain formatting is used for non-user-visible purposes such as logging or constructing protocol messages, and no translator should have to deal with those format strings picked up by the extractor tool to clutter the catalog. Also, for plain strings, a tr!("foo") looks more logical than a fmt! with no formatting parameters. Best regards, Mikhail
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
