-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Split core language files into plugins where possible #5863
Comments
Sounds good. Moving the translations to the according plugins shouldn't be hard. The script for automatic updates is already able to handle that. Are you going to move them? Or shall I put it on my todo list? |
I will have a look later |
Should be enough to move the english translations to the plugins and run a translations:update. |
FYI: Instead of 10ms it takes 30ms on my local VM now (APC enabled). Time is primarily spent in |
I reverted moving the translations into the core again as of course only translations of activated plugins are available. The tests fail when for instance Actions is not activated. Same would of course happen in the UI. |
Hm. Thats right. Imho we have two options. Always load translations from all plugins (including deactivated) or move all translations from core plugins to main language files. |
…ns and keys. Will be only shown if development mode is enabled. Very useful for plugin developers who want to reuse existing translations
@mattab what do you think regarding splitting the translations into plugins and the problem with not activated core plugins resulting in not existing translations. Of course we could always load the translations of all core plugins but not sure about this. Maybe there is another solution? |
+1 for moving the translations into files in each plugin, as this brings better reliability and showcases how to use the platform. loading core plugin translations all the time sounds like a fine solution to the "not available translations issue". Performance: users will really need a APC opcache to cache all these file hits... Maybe we could add new System check setting warning user in case he does not use APC or other supported opcache? |
I would add an caching layer for the translations. Each language would have |
…e always load all translations of all plugins that are not 3rd party and bogus. As the translation file will be cached the time to load the translation drops from > 10ms to 1ms
@sgiehl can you have a look at the |
Sure. I'll have a look |
OK. Should work now. Last branch build was green |
…r will try to load plugin translation directly after loading the plugin when the plugin translations are not loaded yet. Maybe better fix would be to defer loading the plugin getInformation until needed. Could also bring performance improvement
Thx! FYI: I was only looking at an Admin page but the time spent in |
…therwise langCode will be always an empty string. If there is no plugin loaded yet and no language generate a simple cache file for core translations, load a translation only if a langCode is there
FYI: created #6060 |
I think as part of our "move code from core to plugins" we should also move the translations from core to the plugins. For instance all translations from group "Actions" into "Actions" plugin.
A minor disadvantage of this solution could be performance since it would have to load a few more language files. Not sure how much slower it would make it, don't think too much as it checks for each plugin whether a language file exists anyway. We could otherwise still cache all translations in a cache file and make it even faster than it is currently.
Another disadvantage I see is it makes it more complicated to search for existing translations. Here one could still use the LanguagesManager API or if we cache all existing translations in a cache file anyway one could still search there. On the other side it is already right now hard for plugin developers to find existing translations and keys. Maybe we could have a little page in the Admin or somewhere if development mode is enabled which allows a developer to search for translations and keys. Should be easy to implement.
BTW: if plugin developers are supposed to reuse existing translations and we rename/remove keys than this is breaking the API a well and should be mentioned in a changelog (we could link from there to a separate page showing all the detailed translation changes).
cc @sgiehl
The text was updated successfully, but these errors were encountered: