Hi @luca.g,
That’s the site-wide plugins page; check the journal-specific plugins page in Settings. You’ll need to be logged in as a Site Administrator in order to be able to install plugins, but you can browse them as a Journal Manager.
Regards,
Alec Smecher
Public Knowledge Project Team
@asmecher You’re right, thank you for your help. I now see the gallery and they’re all all there. Nevertheless the ‘default translations’ plugin is shown as ‘up to date’, which means I correctly installed (manually) the correct and most up-to-date version, right?
At any rate, at least I’ve found this famous plugin gallery!
Hi @luca.g,
If you think you might’ve installed the Default Translation plugin manually (e.g. via CPanel rather than through OJS), you might need to run…
php lib/pkp/tools/installPluginVersion.php plugins/generic/defaultTranslation/version.xml
…to get the plugin to properly register with the system.
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher,
as I wrote above, by manually I mean by uploading the .tar.gz file into the “Upload A New Plugin” tool on the Plugins page. Do I still need to do that extra step?
Hi @luca.g,
No, uploading the .tar.gz file into the “Upload a New Plugin” tool should have created the registration for you – but you can double-check with the following SQL query:
SELECT * FROM versions WHERE product='defaultTranslation';
You should get something like…
+-------+-------+----------+-------+---------------------+---------+-----------------+--------------------+--------------------------+-----------+----------+
| major | minor | revision | build | date_installed | current | product_type | product | product_class_name | lazy_load | sitewide |
+-------+-------+----------+-------+---------------------+---------+-----------------+--------------------+--------------------------+-----------+----------+
| 1 | 1 | 1 | 1 | 2020-12-16 22:47:14 | 1 | plugins.generic | defaultTranslation | DefaultTranslationPlugin | 1 | 0 |
+-------+-------+----------+-------+---------------------+---------+-----------------+--------------------+--------------------------+-----------+----------+
1 row in set (0.001 sec)
Regards,
Alec Smecher
Public Knowledge Project Team
Thank you @asmecher
yes, it’s there:
1 1 1 1 2020-12-16 16:18:56 1 plugins.generic defaultTranslation DefaultTranslationPlugin 1 0
Hi @luca.g,
What do you mean by “switch button”?
Regards,
Alec Smecher
Public Knowledge Project Team
Sorry - this time I was talking about the ‘language toggle block’ which is checked and which doesn’t show up on the front-end. I have two languages installed, the ‘language toggle block’ enabled, and still I can’t get the front-end to let you choose which language you want to display the site on.
Hi @luca.g,
Hmm, it seems like broadly speaking you’re having trouble with plugins. I wonder whether it’s something specific to your installation rather than a broader problem with the software. Could you try installing a fresh copy of the latest 3.2.x (e.g. to a new database and installation directory on the same server) and see whether the issues you’re encountering apply to that installation as well?
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher,
I just installed it the other day, and I’m afraid I cannot reset the database again. I only have issues with the “language toggle block” actually. The other plugins now work fine, and I was looking in the wrong section, as you pointed out.
Speaking of which: why is there no gallery site-wise? There’s a ‘upload new plugin’ anyway, so it’s not that in the ‘site settings’ one cannot install plugins. If anything, in my opinion, if you want to differentiate site- and journal- wise. there should be the complete view of plugins site-wise (i.e. installed and installable, via upload and gallery), and then in the journal setting you can only enable or disable the ones for that specific journal. Just a thought.
Anyway, I have problems with the translation, and it happens that the plugins linked to the translation are not working correctly (i.e. the switch) other than the issue described here, so, again, I suspect that my problem is with the system not being happy with the Gaelic locale.
Ok coming back to the original question. Where is this common.po that you’re referring to? I can’t find that anywhere under https://translate.pkp.sfu.ca/projects/ojs/
in /lib/pkp/locale I find a list of locales, all containing the .po files. The issue is that gd_GB (Gaelic, the extra language we’re using) is not there. Is this normal? Could this be the reason why we have those annoying hashtags everywhere (with the Default Translation plugin active, that is)?
Hi all,
@akerbeltz wrote:
Where is this common.po that you’re referring to? I can’t find that anywhere under Open Journal Systems @ Weblate
There are components of the software that are shared between OJS, OMP and OPS; those are in the PKP Web Application Library in Weblate (and lib/pkp/locale/... in an OJS installation).
@luca.g, does this answer your question as well?
Could this be the reason why we have those annoying hashtags everywhere (with the Default Translation plugin active, that is)?
This is probably because the content you’re seeing ##with.untranslated.hashtags## was installed in the database when the journal was created – it’s translated at that point, and enabling/installing the default translation plugin won’t affect it.
Regards,
Alec Smecher
Public Knowledge Project Team
You know, that’s the kind of thing that would be helpful to point out in very large print to new projects. There’s us thinking we’ll translate the files that seem to be end-user facing in OJS and OMP and that’ll be dandy. No, there’s an extra 2k (at least) which are hanging around in a totally different place that you somehow have to guess your way to 
Hi @akerbeltz,
Have a look at How Content is Organized in Weblate in the translation guide.
Regards,
Alec Smecher
Public Knowledge Project Team
Maybe you’ve never had to translate into a language smaller than German/French/Russian/Chinese so I’ll explain: most languages are not that blessed with localizers and as a result have to prioritise translator capacity. Often it takes a small to medium locale (SML) much longer to get a translation to 100% and in many cases, they’ll never get there but that may still result in a decent end-user experience if the translation is cleverly managed.
For example, on Mozilla, many SMLs will not localize the dev tools or help. VLC actually has a specific high-priority po specifically curated so SMLs can quickly get VLC to a stage where most of the commonly seen UI is localized.
So yes, obviously if someone wants a full user experience for PKP stuff, you need to translate everything, that’s so obvious it doesn’t need stating to that extent in the guide. But there’s still a priority gradient that makes certain files more important to tackle first for a reasonably localized UI. The guide should therefore ideally state which po files are end-user facing and which are admin back-end and in the case of files like common.po, there should be a clear list of files which are high priority for a product like OJS that sit OUTSIDE the OJS set of files.
We had a limited budget for this project and 100% translation was never going to be possible but because the common.po is not mentioned anywhere as being SO key to the UI, we didn’t include it in out translation planning.