Defining translations inside engines

I’ve noticed that publicOnly does not play well with engines. If enabled, the generated translation file is placed in the host app’s translations dir and not in the engine’s translations dir.

Disabling publicOnly also doesn’t work, because the translation is not bundled into engine.js or engine-vendor.js, but seemingly gets merged into the host app’s app tree:

https://github.com/ember-intl/ember-intl/blob/57691dd4af26d9722bd00a2ae01284d303e14b35/index.js#L111-L142

Input

publicOnly: true

client
├── package.json       # name: "client"
├── app
│   └── ...
└── translations
    └── de-de-x-host.yml

client-packages/engines/
└── direct-sales
    ├── package.json   # name: "@clark/engine-direct-sales"
    ├── addon
    │   └── ...
    └── translations
        └── de-de-x-engine.yml

Expected Output

dist
├── asset-manifest.json
├── assets
│   ├── client.js
│   └── vendor.js
├── engines-dist
│   └── @clark
│       └── engine-direct-sales
│           ├── assets
│           │   ├── engine-vendor.js
│           │   └── engine.js
│           ├── config
│           │   └── environment.js
│           └── translations
│               └── de-de-x-engine.json
└── translations
    └── de-de-x-host.json

Actual Output

dist
├── asset-manifest.json
├── assets
│   ├── client.js
│   └── vendor.js
├── engines-dist
│   └── @clark
│       └── engine-direct-sales
│           ├── assets
│           │   ├── engine-vendor.js
│           │   └── engine.js
│           └── config
│               └── environment.js
└── translations
    ├── de-de-x-host.json
    └── de-de-x-engine.json

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 of treeForApp. In general, we might want to allow addons that specify ember-intl as a dependency to configure this.

[brettburley]

I’ve been playing around with ember-intl with ember-engines a bit to see what the current behavior is.

@buschtoens does your engine itself list ember-intl as one of its dependencies in the package.json? In the testing I’ve done, I’ve found that as long as it’s listed there, both variants of publicOnly will bundle the translations into either the engine.js or engines-dist/engine-name/translations/ files as appropriate. However, it will also hoist them into the app’s translation files as well because of the general addon behavior @jasonmit described.

Including this issue, here’s a list of current behavior that was unexpected to me when using ember-intl with engines:

1. The host application gets all engine’s translations bundled into its translation files.
2. Each engine has a translation file that includes the same set as the host app (i.e. all of the host app’s translations, all of the host app’s engines’ translations, and all of the host app’s addons’ translations).
3. ember-intl uses the config for the host app when building translations for each engine (e.g. if the host app is publicOnly true, this will apply to all engines, regardless of what ember-intl config they may define locally).

The first issue is a result of treating all addons the same, as @jasonmit mentioned, in buildTranslationTree: https://github.com/ember-intl/ember-intl/blob/master/lib/broccoli/build-translation-tree.js#L15, and the later two issues are a result of using this.app and this.project in https://github.com/ember-intl/ember-intl/blob/master/index.js#L50 which point to the host app, rather than using this.owner which would represent the engine’s own config/path. I think for engines that the current behavior of bundling into the host app is superfluous, since those keys are likely not used, but not sure how folks might currently be using this behavior and how many applications might break as a result.

Given that the local intl service in an engine will look up translations only for the engine (since config.modulePrefix is the engine name), I think I would expect that translations would be scoped to the engine. Also @buschtoens, I think the current behavior of using the treeForApp hook even for engines is correct since ember will put these files into the engine’s namespace already (since the all of the app’s modules are namespaced). I think that I would also expect the engine’s ember-intl config to be respected since the engine has to make assumptions on how to initialize the service and potentially load translations depending on that setting. If it depended on the host apps config, the engine wouldn’t know if it needs to fetch its own translations, for example.

[srsgores]

Has anyone found a workaround for this? We’re about to migrate over to engines and would like a solution if anyone has one.