Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork9.7k
[RFC][Translation] Deprecate resource_files in translator#32735
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
| * @dataProvider getDebugModeAndCacheDirCombinations | ||
| * @group legacy | ||
| */ | ||
| publicfunctiontestResourceFilesOptionLoadsBeforeOtherAddedResources($debug,$enableCache) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
With these changes, the following option is now unsupported
'resource_files' => ['some_locale' => ['messages.some_locale.loader']]
so a work-around will be needed for this scenario (Maybe adding a new option set loaders per locale?)
| * | ||
| * * cache_dir: The cache directory (or null to disable caching) | ||
| * * debug: Whether to enable debugging or not (false by default) | ||
| * * resource_files: List of translation resources available grouped by locale. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
the new option should be added
stof commentedJul 25, 2019
I know for sure that this will impacthttps://github.com/willdurand/BazingaJsTranslationBundle, which inspects the definition of the translator service to get the list of resources for its translation finder. The new logic would force the bundle to duplicate the whole location of file resources (maybe this indicates a need for a new service in core, so that they can use the same service than the translator rather than duplicating some internal logic). |
nicolas-grekas commentedSep 27, 2019
Then we should ensure the new logic exposes a way to get the list of resources from the translator cache.@pierredup do you think it possible? |
fabpot commentedFeb 3, 2020
Closing as there is no more activities on this PR (and it cannot be merged as is). Fee free to reopen if you want to finish it. |
Uh oh!
There was an error while loading.Please reload this page.
The list of resource files is cached by the container at compile time. This means that any change in translation files (adding/removing a file) needs a rebuilt container t take effect.
This PR proposes to deprecate this behaviour and let the translator manage its own resources fully.
This approach is to pass a list of directories to the translator instead, which the translator can use to determine if the cache needs to be rebuilt. Any change in the directories means only the translator cache will be rebuilt while the container cache stays untouched.
The only time the container needs to be rebuilt is when a new translation directory is added (E.G when adding a new bundle).
I'm not 100% sure what effect this will have on 3rd-party bundles (I.E if a bundle explicitly requires this behaviour and can't pass directories instead), so any insights would be appreciated.