Skip to content
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

Closed
tsteur opened this issue Jul 21, 2014 · 14 comments
Closed

Split core language files into plugins where possible #5863

tsteur opened this issue Jul 21, 2014 · 14 comments
Assignees
Labels
Task Indicates an issue is neither a feature nor a bug and it's purely a "technical" change.
Milestone

Comments

@tsteur
Copy link
Member

tsteur commented Jul 21, 2014

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

@tsteur tsteur added this to the 2.5.0 - Piwik 2.5.0 milestone Jul 21, 2014
@sgiehl
Copy link
Member

sgiehl commented Jul 21, 2014

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?

@tsteur
Copy link
Member Author

tsteur commented Jul 21, 2014

I will have a look later

@sgiehl
Copy link
Member

sgiehl commented Jul 21, 2014

Should be enough to move the english translations to the plugins and run a translations:update.

tsteur added a commit that referenced this issue Jul 21, 2014
@tsteur
Copy link
Member Author

tsteur commented Jul 21, 2014

FYI: Instead of 10ms it takes 30ms on my local VM now (APC enabled). Time is primarily spent in file_get_contents

tsteur added a commit that referenced this issue Jul 21, 2014
@tsteur
Copy link
Member Author

tsteur commented Jul 21, 2014

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.

@sgiehl
Copy link
Member

sgiehl commented Jul 21, 2014

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.

tsteur added a commit that referenced this issue Jul 22, 2014
…ns and keys. Will be only shown if development mode is enabled. Very useful for plugin developers who want to reuse existing translations
@tsteur
Copy link
Member Author

tsteur commented Jul 22, 2014

@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?

@mattab
Copy link
Member

mattab commented Aug 3, 2014

@tsteur @sgiehl

+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?

@sgiehl
Copy link
Member

sgiehl commented Aug 3, 2014

I would add an caching layer for the translations. Each language would have
it's own combined file in the tmp directory as soon the language is used
the first time.
For sure all translation cache files need to be cleared upon updating piwik
or adding, removing or updating a plugin.
That would minimize the stat calls...

tsteur added a commit that referenced this issue Aug 24, 2014
…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
tsteur added a commit that referenced this issue Aug 24, 2014
@tsteur
Copy link
Member Author

tsteur commented Aug 24, 2014

@sgiehl can you have a look at the Plugins/LanguagesManagerTest and Translate/WriterTest. I think they are the only ones that fail see https://travis-ci.org/piwik/piwik/builds/33435368 but I do not really know how to best adjust code/tests to make them green again. Code is in branch 5863_languageFilesInPlugin.

@sgiehl
Copy link
Member

sgiehl commented Aug 24, 2014

Sure. I'll have a look

@sgiehl
Copy link
Member

sgiehl commented Aug 24, 2014

OK. Should work now. Last branch build was green

tsteur added a commit that referenced this issue Aug 25, 2014
…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
@tsteur
Copy link
Member Author

tsteur commented Aug 25, 2014

Thx! FYI: I was only looking at an Admin page but the time spent in loadPluginTranslations() reduced from 200ms on average to 5-20ms. Both APC enabled

tsteur added a commit that referenced this issue Aug 25, 2014
…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
@tsteur
Copy link
Member Author

tsteur commented Aug 25, 2014

FYI: created #6060

@tsteur tsteur closed this as completed in 07ee831 Aug 25, 2014
@tsteur tsteur self-assigned this Aug 25, 2014
@tsteur tsteur modified the milestones: Short term, Piwik 2.6.0 Aug 25, 2014
tsteur added a commit that referenced this issue Aug 25, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Task Indicates an issue is neither a feature nor a bug and it's purely a "technical" change.
Projects
None yet
Development

No branches or pull requests

3 participants