Hi there,
a while ago I requested feedback on my Elm Code Generator for Internationalization (I18n).
I’m very happy with the recent breakthrough regarding Fluent compatability which I want to share with you
I’m also interested in feedback as always.
Pass the default export of intl-proxy into your Elm program as a flag
Pass the intl-proxy into the generated I18n constructor
After that, the locale specific features like matching on PluralRules or formatting numbers and dates just work! The trick is runtime decoding of a JS proxy object, if you have any questions go ahead and ask me
Additionally, I created a webpack plugin (travelm-agency-webpack-plugin - npm) to make usage of the code generator more convenient.
Are there any other build tools you want to see supported? Personally I have only used parcel and webpack for Elm so far.
I didn’t run into those yet, I guess my projects so far did not need translation management.
Could you provide a concrete example, what you would like to be possible?
I imagine it would be some kind of plugin like the webpack one I created?
We are close to start using translation management services, but we didn’t start yet, but probably what is needed in the tech side will be provided by the services themselves, like a cli tool to export the data in fluent’s .ftl format.
Okay so you would export the translations from the service to .ftl files and then run travelm-agency to generate the corresponding elm code. Should work right?
I am of two minds about this. On the first hand, this is both very neat and very impressive. On the other hand, intl-proxy scares me, because it brings back (somewhat limited) JS FFI and thus a lot of the concerns around Kernel code.
I have also dabbled in Elm-generating-Elm, and believe that whatever hacks you want to use during that are fine, because at the end of the process you either have valid Elm code or you don’t. However, I see in the examples that some use cases require the use of intl-proxy in the application that uses the generated code. Would you consider moving to a pure-Elm solution for locale-aware formatting if one was available?
Blatant plug: I started on such a pure-elm library, although it is not feature-rich enough yet to cover this use case: elm-cldr 1.0.0
Yes, I feel similarily about the proxy hack. It works very well, but its almost as powerful as straight up kernel code. Sadly, it’s the only approach right now that allows synchronous interop, which is needed in my opinion for internationalization.
I would gladly add a command line/API option to choose between intl-proxy or elm-cldr.
The default should probably be elm-cldr if its features are enough for the given translation sets.
This shouldn’t be a problem to implement, I’m doing the same currently to avoid depending on intl-proxy if it isn’t necessary.
