Thanks for feedback! It looks like a decent lib and I would recommend anyone who need richer i18n support (like plural forms) take a look.
As for a18n, it's a deliberate choice to use current format (JSON with extracted key/value pair) instead of standard like ICU messageformat. Here are reasons:
1. This lib is built to enable automated i18n workflow for existing projects (~200kloc), with minimal human interfere and impose minimal complexity for build configuration, in this regard current format is working great.
2. This lib is used by both projects, plugins and components in our company, so to keep its footprint down (in case it's not deduped by bundler), it means fewer features (like plural forms, date, list) are supported, and...
3. ...we originally planned to add support for ICU messageformat if these features are desired. But after two years in production, we found the demand is not too strong to justify the cost.
Not an English speaker but this is still awkward: I always think "i18n" expands to 18 characters until I see your comment and checked `"internationalization".length` in console to be 20
Thank you! This concern is valid. If we change original (let's say) Chinese texts in code, and re-run the CLI (wrap+extract). These happens (in my company's workflow):
1. CLI removes (oldKey -> oldValue) entry from en.json (a18n don't keep stale keys)
4. A script (not in a18n yet) scans en.json, found untranslated text and warns
5. It's up to the developer to decide what to do with missing translation
Not too perfect, but I think keeping original text in code instead of "some.text.id" also has its benefit:
1. Devs understand the texts, this brings more context and makes code easier to understand
2. Some huge projects in my company exists long before they need to support i18n, and it is just too expensive to manually migrate from `text` to `code`
Thanks! Yes, Automation is what actually I thought of the 'a' in a18n :)
But it's named as `a18n` for some complicated reasons:
1. It aligns well with translation function name and CLI command
I want the translation function to be something:
- looks like `i18n` (so user can tell its purpose at a glance)
- but NOT `i18n` (so it's unique enough that we can safely assume its role when we parse/manipulate user's code)
- also NOT too short like '_', or 'i' (for the same reason above)
By these rules, I think `${someChar}18n` is a great fit as the function name, and to simplify things, I just use it as the CLI name and the package name.
2. (the real reason) It's really hard to name a JavaScript i18n lib today
If you search for "i18n" in npm, more that 7000 libs pops up. Here is a list of lib names I searched and found taken:
- simple-i18n
- i18n-simple
- s18n
- v18n
- next-i18n
- i18n-next
- react-i18n
- i18n-react
- ...(maybe 20 more?)
So when I finally found that `a18n` is not taken? -- I know instantly it's a digital treasure that I have to grab :)
As for a18n, it's a deliberate choice to use current format (JSON with extracted key/value pair) instead of standard like ICU messageformat. Here are reasons:
1. This lib is built to enable automated i18n workflow for existing projects (~200kloc), with minimal human interfere and impose minimal complexity for build configuration, in this regard current format is working great.
2. This lib is used by both projects, plugins and components in our company, so to keep its footprint down (in case it's not deduped by bundler), it means fewer features (like plural forms, date, list) are supported, and...
3. ...we originally planned to add support for ICU messageformat if these features are desired. But after two years in production, we found the demand is not too strong to justify the cost.