Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Fluent #41

Open
1 of 5 tasks
cibernox opened this issue Mar 1, 2022 · 4 comments
Open
1 of 5 tasks

Support Fluent #41

cibernox opened this issue Mar 1, 2022 · 4 comments

Comments

@cibernox
Copy link
Owner

cibernox commented Mar 1, 2022

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.

  • 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...
@ivanhofer
Copy link

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.

@cibernox
Copy link
Owner Author

cibernox commented Mar 2, 2022

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.

@ivanhofer
Copy link

Cool 😎.
I'm looking forward for your addition of the Fluent syntax and the resulting changes to this library.

@ambigos1
Copy link

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.

Hi @cibernox .
Any update since Mar 2022 regarding support for typesafe-i18n.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants