ember-intl
[Idea] Codemod to separate 1 translation file into multiple
At EmberFest 2024, I heard from a couple of teams that they (just like mine) struggle with maintaining 1 translation file, which grew over time, with keys lacking a pattern. The only suggestion that I could provide was to use eslint-plugin-yml to sort the keys, to provide some uniformity.
The idea is to write a codemod that analyzes in which component and route templates the translations have been used, then create multiple files with a folder structure that matches that for components and routes. The codemod would rename keys whenever possible, and only if the end-developer wants this to occur.
To avoid creating too many translation files (e.g. due to deeply nested components or routes), the codemod may group translations at "folder level 2". This feature is a nice-to-have, not a must.
-
<Hello>→ components/hello.yml -
<Ui::Form>→ components/ui/form.yml -
<Ui::Form::Input>→ components/ui/form.yml -
<Ui::Form::Textarea>→ components/ui/form.yml
@ijlee2 you can have multiple translation files per locale within translations but that may not be a well known feature.
Similarly, years ago I wrote an addon that would merge all the translation files from anywhere within the parent app's components tree. Unfortunately I think it was for a past employer so I don't have the code handy but can be reimplemented by creating an addon that implements treeForTranslations and returns a broccoli node / tree of the translations via broccoli filter / funnel.
The one thing I never worked out was strict scoping of the translation keys to their component - ideally that functionality exists.
APIs likely have changed since I last recall them, I've been out of the Ember community for many years, but figured I'd share what I knew.
Hi, @jasonmit. Thanks for sharing what you know. Both having multiple translation files and using treeForTranslations() hook to merge translations are known to me.
The idea that I had is more for large monorepos: If translations for many addons live in one package, can we write a program to split and move the translations, so that each addon can be responsible for providing the translations that it needs (to ease maintainance)?
As an aside, I'd be glad to learn more from you some day about the files in lib. I'd like to (or need the community's help) convert ember-intl to be a v2 addon, and currently have no idea what to do with these files, which require an in-depth knowledge of broccoli. 😅
If translations for many addons live in one package, can we write a program to split and move the translations, so that each addon can be responsible for providing the translations that it needs (to ease maintainance)?
@ijlee2 Do you want to do this at build time to pull the translations from the one "shared translations addon" into the parent app - or were you thinking more codemod tool to move translations from the one location to the addons?
The former I think can be achieved with current APIs where the individual addons would implement treeForTranslations and would pull translations in from the "shared translations addon". A solution might look similar to https://github.com/ember-intl/ember-intl/issues/401#issuecomment-506496579 but would require.resolve() the shared addon and broccoli-funnel / filter over that whatever translations you're trying to pull in.
For the v2 addon API, I'd have to investigate what that migration looks like. We're not doing anything unconventional with the existing treeForPublic / treeForAddon hooks - so I'm hopeful there's a migration path. If you have any questions about the behavior in index.js I can help walk through areas of it as I recall them.