Internationalization bindings and Mozilla's Fluent

#1

Hi all,

I am planning a move from Elm to Bucklescript (most probably using bucklescript-TEA via philip2), and I have a whole bunch of questions relating to Intl and other internationalization/localization topics. It’s probably going to make most sense for me to explain and ask all my questions at once.

My current localization solution for my Elm project is elm-fluent - a Fluent to Elm compiler that I wrote myself. Fluent is Mozilla’s next generation l10n solution that I’ve got fairly involved with recently - in addition to elm-fluent I’ve written two Python implementations for Fluent, and a Django wrapper, because my app is a hybrid - mostly server generated, Javascript-light pages, with a few central client side heavy pages for which I need Elm (or something similar).

So I’m fairly heavily invested in Fluent as an l10n solution at the moment, and I’m planning on staying that way, because it is a very nicely designed system, and elm-fluent turned out really well. So I’m thinking about how to port all of this to Bucklescript.

One of the issues is that the Fluent spec includes number and datetime formatting, and specifies the built-in functions in terms of Intl.DateTimeFormat and Intl.NumberFormat.

For elm-fluent, I was using an Elm wrapping of these browser APIs provided by elm-intl, which is very nice (unfortunately only for Elm 0.18, and Elm 0.19 has restricted the usage of this kind of library, with no workaround, which is one of my blockers on Elm 0.19).

As far as I can see, Bucklescript’s standard library does not yet wrap Intl at all, but recently I have found bs-intl.

Question 1 - are there other places I should be looking or other community efforts I should know about?

Question 2 - are there any plans to get something like this in the standard library, or should I be just using a community package and contributing to that?

Once that is resolved, I’ll need to think about re-writing elm-fluent to target OCaml/Bucklescript instead of Elm.

I think that will be mostly straightforward due to the similarities at the language level, and the way I’ve written the compiler so that code generation is mostly separated out. But I still have a ton of questions:

Question 3 - is there likely to be interest in the wider OCaml community for something like this, or should I just be focusing on Bucklescript/Reason?

Question 4 - is there is interest in the ReasonReact community? Given the design of elm-fluent, which I think will map very well across to Bucklescript, most of the API will be usable from both something like ReasonReact and bucklescript-tea, as most of the time you just need plain text messages, not HTML. For elm-fluent, I did have a pretty nice solution for messages that embed HTML, and this was specific to the Elm virtual DOM, which I think will map very nicely to bucklescript-TEA, and perhaps something similar could be done for ReasonReact.

Question 5 - The elm-fluent compiler is currently written in Python, and when I port it to output Reason/Bucklescript instead I will most likely start from a fork of that project, rather than start from scratch. Is this use of Python likely to hinder adoption in Bucklescript world? I’d be very open to having a OCaml/Bucklescript/Reason implementation etc., but don’t know when I’ll get the time for something like that.

Question 6 - Is anyone interested in helping with any of this? :slight_smile: For me this is all in aid of a side project, not paid work, and I have a very small time budget for this, so any help would be greatly appreciated. In addition, for some questions about what the output of the Fluent-to-Bucklescript compiler should produce I’d really value the input of someone with more experience.

Thanks! As mentioned I’m busy with other things so may not be able to reply very quickly.

Luke

#2

Re: Question 2, Intl might rather belong to bs-webapi, but so far it’s missing from that lib either.

As for the Question 6, I think that strongly depends on the community interest. Personally, my time budget is equally small, so probably I’d rather contribute to Belt or to documentation before helping with something nobody might actually have use for.

P.S. Not that this is a personal perspective of someone who just dabbles with Reason in what little spare time he has. I’m sure that people whose day job involves Reason know better.

#3

Hi, I hadn’t heard about Fluent, it looks really interesting. I’ll try to answer your questions.

  1. Community-maintained packages are in https://github.com/reasonml-community/ , there is also https://redex.github.io/ which is more of a self-serve package index. You can search these to see if anyone has contributed Fluent bindings.
  2. I agree with hoichi that the Intl.* bindings should go into bs-webapi–but it needs someone to go through the normal issue/PR process to drive it forward. If you’re asking about Fluent itself, that doesn’t seem like a standard Web API so I would think it should be in a third-party package.
  3. In the wider OCaml community (targeting native compilation) I think gettext is the norm. See e.g. http://opam.ocaml.org/packages/ (search i18n). But Fluent seems general-purpose enough that it could potentially be useful to anyone who’s doing serious frontend work, whether web or native. E.g. I can see how it might be very useful to @bryphe’s Revery UI project and Onivim2 editor.
  4. In the ReasonReact community the first instinct would probably be to write ReasonReact bindings to the Fluent React API ( https://github.com/projectfluent/fluent.js/tree/master/fluent-react ). Depending on how exactly Fluent React works, it may be feasible or not. I notice that it uses a style of putting the Fluent messages inline inside an l10n.js file instead of separate .ftl files.
  5. The use of Python may make it a bit more difficult to achieve reproducible builds. Ideally we would have a JavaScript/BuckleScript/native OCaml binary that would do the compilation from .ftl to OCaml modules. In the OCaml world we also a have really nice parser generator Menhir and I believe @ELLIOTTCABLE has even done some work to port it to BuckleScript: https://github.com/ELLIOTTCABLE/bs-sedlex#parser-writing-tips-from-a-fellow-javascripter
  6. Hard to say right now, as you know it’s difficult to invest a lot of time into stuff unless you have a chance of shipping it :slight_smile: But definitely drop by the ReasonML Discord and voice the idea, I’m sure people will at least have feedback.

[EDIT: I just found this which also does something interesting re: i18n: https://github.com/bloodyowl/reason-i18n-extractor ]