|
So the way I'm reading the autoloader and fact loader code, it looks like for Ruby files, we load files from locally installed modules first, then pluginsynced stuff. Conversely for facts, we load pluginsynced stuff first, then local custom facts.
In the case where there are no duplicate modules (and therefore no duplicate translations), this is fine. But it raises an interesting trade-off if there are both local and pluginsynced copies of data with the same name. The way we currently handle translation files, we only allow loading a PO file with a given name once. This means in the case where a user both has a module installed locally and has translations from a module of the same name pluginsynced, we will only load translations from whichever source we search first. Translations for all parts of a module (stuff in lib, facts, and manifests) are all loaded as one atomic PO file, one per module, so we can't choose different load orders from different parts. This could lead to surprising gaps in translations, that might be different across different operations.
The alternative is to change the way we construct the text domains, to allow multiple repositories of the same name in a chain (note that the repository name HAS to correspond to the name of the PO file being loaded). We currently don't allow this because in the model where we were loading translations each time a module was loaded, this would have led to explosion of translations in memory, as well as tons of extra work. As we move to being more efficient about what we load and when, this might have less of an impact, but it could still lead to unnecessary duplicates, and it will remove any limit on the size of the repository chains (if we accidentally load things more times than we think we are, we will see the chains get very long). The benefit, however, is that we always will have all translations available in cases where we need to search both $modulepath and $vardir.
Michael Smith or Josh Cooper thoughts?
|
