-
Notifications
You must be signed in to change notification settings - Fork 167
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
Defining translations inside engines #797
Comments
Yeah, it takes the same path as an addon so the behavior of bundling into the app is expected. This works sufficiently for most, but I could see how someone might expect scoping of some sort and the translations bundled into the engine bundle. That said, the behavior of |
I've been playing around with @buschtoens does your engine itself list Including this issue, here's a list of current behavior that was unexpected to me when using
The first issue is a result of treating all addons the same, as @jasonmit mentioned, in Given that the local |
Hello everyone, My question is a bit opposite. I do see translations as a copy of translation folder from the host app in every in-repo engine. can I somehow disable this generation? We load them manually (publicOnly: true) and honestly I see no reason in this sort of "duplication". What do you think? |
In our app all our engines are lazy + nested lazy. So, ember build creates a copy of translation folders in every engine. I created a test repo https://github.com/catz/lazy-intl-frontend
I suppose there might be some reason to do builds that way but I can not figure out it especially when publicOnly is true. Does that all make sense ? |
Has anyone found a workaround for this? We're about to migrate over to engines and would like a solution if anyone has one. |
I've noticed that
publicOnly
does not play well with engines. If enabled, the generated translation file is placed in the host app'stranslations
dir and not in the engine'stranslations
dir.Disabling
publicOnly
also doesn't work, because the translation is not bundled intoengine.js
orengine-vendor.js
, but seemingly gets merged into the host app's app tree:ember-intl/index.js
Lines 111 to 142 in 57691dd
Input
publicOnly: true
Expected Output
Actual Output
Problem
If the engine and host app would share the same locale name, e.g. just
de-de
, one would clobber the other. Moving this to the "root" also makes it harder for an engine to reliably load the translation, I would assume.I think this is just an oversight, since ember-intl has rarely been used with ember-engines.
Solution
We special-handle engines and merge into
treeForAddon
instead oftreeForApp
. In general, we might want to allow addons that specifyember-intl
as a dependency to configure this.The text was updated successfully, but these errors were encountered: