News for hackers. Stuff that matters.

A comment on Fluent 1.0: a localization system for natural-sounding translations. Parent comment

Re:Fluent 1.0: a localization system for natural-sounding tr... by lewisl9029 on Wednesday April 17, 2019 @05:50AM (#19681129)
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 oriented approach to i18n could maybe look something like this:

  const DefaultMessage = ({ clickCount }) => 
    <span>
      Please <a>click here {clickCount} 
      {pluralize(clickCount, {one: "time", other: "times"})}
      </a> to confirm
    </span>

  // some theoretical language that requires putting "to confirm" between 
  // "click here" and "7 times", using English for clarity
  const MessageInSomeOtherLanguage = ({ clickCount }) => 
    <span>
      Please <a>click here to confirm {clickCount}
      {pluralize(clickCount, {one: "time", other: "times"})}
      </a> 
    </span>

  // some theoretical component that renders different components 
  // based on the language and passes through props
  <FormattedComponent
    id="confirm"
    defaultMessage={DefaultMessage}
    props={{ clickCount: 7 }}
  />
This feels a lot more elegant and flexible to me. Though it would make it more difficult for non-technical folks to contribute to translations, which might not be much of a concern if your company has the resources to support localization teams in-house. Am I overlooking any other obvious downsides to this approach? Does anyone know of any libraries that offers a similar API, or have experience using a similar approach?
[ Parent | on HN ]
Re:Fluent 1.0: a localization system for natural-sounding tr... by madeofpalk on Wednesday April 17, 2019 @07:18AM (#19681521)
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.

[ Parent | on HN ]
Re:Fluent 1.0: a localization system for natural-sounding tr... by pas on Thursday April 18, 2019 @09:55AM (#19691007)
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.

[ Parent | on HN ]
Re:Fluent 1.0: a localization system for natural-sounding tr... by michaelmior on Wednesday April 17, 2019 @09:04AM (#19682142)
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.
[ Parent | on HN ]
Re:Fluent 1.0: a localization system for natural-sounding tr... by stasm on Wednesday April 17, 2019 @10:44AM (#19682994)
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....

[ Parent | on HN ]
Re:Fluent 1.0: a localization system for natural-sounding tr... by michaelmior on Wednesday April 17, 2019 @11:33AM (#19683462)
Cool! That looks like a great start :) I don't really do any l10n work myself so this was really just a bystanders perspective.
[ Parent | on HN ]
Re:Fluent 1.0: a localization system for natural-sounding tr... by ivan_gammel on Wednesday April 17, 2019 @07:16PM (#19687261)
It will be way easier to maintain, if the L10n resources won’t be mixed with the markup or code. Check this for example: https://github.com/resource4j/resource4j
[ Parent | on HN ]
Re:Fluent 1.0: a localization system for natural-sounding tr... by whoisthemachine on Wednesday April 17, 2019 @08:34AM (#19681940)
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.
[ Parent | on HN ]
Re:Fluent 1.0: a localization system for natural-sounding tr... by lewisl9029 on Wednesday April 17, 2019 @02:02PM (#19684927)
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.

[ Parent | on HN ]