svelte-intl-precompile
svelte-intl-precompile copied to clipboard
cibernox
Support Fluent
One of the main advantages of this library being a build time compiler is that we don't have to bloat the user's app with a parser/tokenizer for understanding translations. All that work happens in build time. A nice byproduct of that, is that this library can support any number of internationalization syntaxes for as long as we can create a compiler that transforms those translations at build time, for free, with zero overhead for consumers.
While the ICU message format is the most popular choice today, the Fluent project (https://projectfluent.org/) is gaining popularity lately. It has a very similar feature set, but a more detailed comparison can be found here.
This issue will track the progress of making this library support both ICU and Fluent simultaneous transparently to the user.
- [x] Make the library not assume ICU is the only possible AST transform (although it is for now)
- [ ] Initial Fluent implementation: Simple strings, plurals and selects
- [ ] Formatters: Dates, times, etc...
- [ ] Automatically select the Fluent transform based on the file extension of the language packages.
- [ ] Fluent unique features: Reference other messages from within messages, BiDI isolation...
Great idea! Do you plan to support also other syntaxes?
Maybe in a generic way so someone could hook into parts of svelte-intl-precomile where the transformation takes place.
I'm working on a lightweight library called typesafe-i18n that uses it's own syntax because it is parse-able with ~400 kilobyte of gzipped code.
I also want to offer preprocessing of translation files so it would not need any runtime parsing and the whole library could potentially add less than 500kb to the resulting bundle size.
I'm working on that precisely. The library that takes the AST of the translations and compiles them is already an independent library (https://github.com/cibernox/babel-plugin-precompile-intl). Until know it only supported one AST transform. When I'm done with this it should support two. Once two are supported, supporting 3 or 4 should be easier.
Cool 😎. I'm looking forward for your addition of the Fluent syntax and the resulting changes to this library.