Still, OJS-3.1.1-4 appears to ship that plugin, and hence to expect a locale translation. Even though that OJS release (Release ojs-3_1_1-4 · pkp/ojs · GitHub) dates after the removal of the usageStats plugin, namely September 2018.
Is this a temporary glitch that will be fixed with a next release, or should a translation for this removed plugin nevertheless be provided? If so, where?
Thanks for clarifying. So far, usageStats is the only one that has moved but is still being reported by the translator plugin in OJS. I’ve nearly finished translating everything, including what’s inside https://github.com/pkp/pkp-lib/tree/master/plugins. Should I just proceed, and commit GitHub - pkp/usageStats separately?
Yes, the best thing to do would be to contribute that translation to the plugin’s separate repository. That plugin is included in the application as a submodule, and then built into the .tar.gz package with each release, so either way you’ll see it present in your local installation even though the code is kept in a separate git repository.
Regards,
Alec Smecher
Public Knowledge Project Team
Ok, I understand the principle. Still, I want to make sure we’re talking about the same plugins here. I have followed the instructions at https://docs.pkp.sfu.ca/translating-guide/en/2-5-sharing, so I assume I have pulled in all submodules with the command git submodule update --init --recursive. Now, when I check my working copy:
I do have: plugins/generic/usageStats
I don’t have: lib/pkp/plugins/generic/usageStats (which, according to the git log, has been removed)
I’m translating on a separate OJS-3.1.1-4 instance I have installed from the release package (I mean, I haven’t built it myself from my git working copy), and moving changed locale files from the server to my git working copy. That OJS instance is reporting a missing locale for the lib/pkp/plugins/generic/usageStats plugin (i.e. the one I don’t have in my git working copy); the translation for the plugins/generic/usageStats plugin (i.e. the one I do have in my git working copy) is complete.
Now, if the lib/pkp/plugins/generic/usageStats plugin hasn’t been imported automatically, does this mean that more is needed than git submodule update --init --recursive to import all submodules? Or, in other words, is there a way to tell which submodules are imported in the working copy, and which have to be maintained elsewhere?
Ah, I understand. Part of the change involved in moving that plugin to its own repository was to take what were previously two parts of the plugin (lib/pkp/plugins/generic/usageStats and plugins/generic/usageStats) and move them together into the new repository. Essentially the plugin was previously split in a few pieces, and moving it to its own repository reconciles those into a single repository. So the lib/pkp part should no longer exist; its contents have been moved in with everything else in the stand-alone repository.
Regards,
Alec Smecher
Public Knowledge Project Team