Missing Key Values for Manual Translations

We are using the manual translation instructions at http://pkp.sfu.ca/wiki/index.php?title=Translating_OxS in order to change some of the language (i.e., key values) that was displaying in the administrative panel. We are currently working on a staging server.

We’re having the difficulty shown below.

15%20PM
Let me describe what we’ve done. I’m hoping for some insights as to how to fix this problem.

Specifically, we created forked repositories from GitHub - pkp/ojs: Open Journal Systems
and GitHub - pkp/pkp-lib: PKP Web Application Library.

We then duplicated the folder content from
ojs/locale/en_US (created: ojs/locale/en_MJ)
and
pkp-lib/locale/en_US (created: pkp-lib/locale/en_MJ).

We edited the needed keys values in each .xml file.
We also added the language in the registry/locales.xml as

In the admin dashboard of our journal, we installed this new language.

Most of the content works except the content that is associated with the file:
pkp-lib/locale/en_MJ/editor.xml.

in the journal dashboard, the key values associated with certain lines in this file simply display as ##editor. <…>##.

I have ensured that the keys that do not apparently have values (and are displaying as “##editor…##”) do in fact have values associated with them. Somehow those values are not being pulled in.

Can anyone help us?

Also, if we decide to instead keep en_US and edit content in the .xml files within that folder, will these be overwritten during the regularly scheduled upgrades?

Our journal is hosted by PKP.

Thanks in advance.

Hi @JManager_Murmuration,

The most common cause for this would be a typo in the XML causing it to fail parsing; you can use a tool like xmllint to ensure that the XML validates properly.

Generally speaking, creating a new locale like this isn’t a practice I’ve seen journals do before. Most will edit the en_US locale files directly, or use something like the Custom Locale plugin.

PKP’s hosting uses git to manage customizations to journals, so modifications to existing locale files would be easy to notice and merge into a new release of the software. A new set of locale files wouldn’t be tracked by git, so would need to be updated manually. (Note that there’s language in the hosting agreement about how modifications are handled on upgrade – your modifications are your own to maintain.)

Regards,
Alec Smecher
Public Knowledge Project Team

Thanks Alec.
We will then go the suggested route of changing the content in en_US.
Upon scheduled upgrades, will we lose the content in en_US/ … xml files?

Hi @JManager_Murmuration,

If you’re hosting with PKP, and make changes to preexisting locale files (e.g. locale/en_US/submission.xml), then those will show up when we survey the installation before upgrading (we use git for this). If these changes are easy to reapply to the new codebase, then the hosting team will go ahead and do that. Generally locale file modifications should be straight-forward to reapply, if you keep your edits clean (e.g. no unnecessary reformatting or rearrangement of the files).

Regards,
Alec Smecher
Public Knowledge Project Team