OJS 3: Correct procedure for customising messages / locale files

Hello all,

We’re loving the new way of making customisations within plugin/themes so that core code doesn’t need to get overwritten (which previous made upgrading a bit of an issue). However, I can’t figure out how to do this correctly for message values in locale files.

For example, we would like to change:


to “Author Information” rather than “Author Biography” / “Author Biographies”.

Within our theme, plugins/themes/ourTheme/locale/en_US/locale.xml, I added the following:

<locale name="en_US" full_name="U.S. English">

        <message key="submission.authorBiographies">Author Information</message>
        <message key="submission.authorBiography">Author Information</message>

But this seems to make no change. The values for submission.authorBiographies and submission.authorBiography are read from lib/pkp/locale/en_US/submission.xml and only if I update them there, does the text update as needed.

What is correct procedure for overwriting message values without having to edit locale library files that could easily get changes in future versions?

Thanks so much in advance.

@asmecher probably can answer this better, but there is probably a specific order how the locale files are loaded. Meaning that whatever you are defining in theme locale file gets overwritten by the actual locale file.

I noticed this a while ago when I was trying to change the labels “Request reviews” and “Resubmit” to “Minor revisions” and “Major revisions”.

1 Like

Hi @ianthe,

Glad to hear the plugin structures are proving useful – we’re really hoping to see fewer code modifications as we improve plugin tools further, as modifications are way harder to maintain during upgrades and sometimes cause users to avoid staying current.

The problem is indeed in the order of locale file loading. I didn’t intend plugin locale files to override existing locale keys, but rather just to add keys that the plugin needs for new UI areas. But I can see the utility in what you’re looking for.

There’s currently no concept of priority in locale file registration – the last locale file to be loaded gets to have the “definitive” say on any locale key it adds, clobbering any past examples of that key.

If you want a chance at overriding the results, you could register for the PKPLocale::translate plugin hook. It gets called after the translation function goes through all the locale keys, but before it returns its last result. See pkp-lib/PKPLocale.inc.php at ojs-3_1_0-0 · pkp/pkp-lib · GitHub for the relevant lines of code.

Alec Smecher
Public Knowledge Project Team


i hope it’s okay if i continue on this older topic. At the moment, i’m trying
to modify an OJS 3 theme plugin in such a way that the plugin’s locale
keys overwrite everything else. However, maybe due to my lack of OJS plugin-writing experience
or my rusty PHP knowledge i’m struggeling quite a bit.

So, i registered for the PKPLocale::translate hook in the plugins init method like this:

public function init() {
    HookRegistry::register('PKPLocale::translate', array($this, 'translateCallback'));

function translateCallback($hookName, $args) {
    echo "Called!<br>";

Initially i would have expected that the is callback invoked for each
string that gets translated. The idea was then, to loop over the plugins
locale files and replace those strings that can be found. But at least in my experiments the callback
seems only to be triggered if no key can be found (that is also my impression
after look at the code of the “translate” method in ‘lib/pkp/classes/i18n/PKPLocale.inc.php’).
Am i missing something and would that be the proper approach anyway?

Thanks in advance.

I have a similar issue with loading translation files from the theme last. @asmecher, could you provide some insight in how to specifically manipulate the loading order of the translate files with the given hook? An example would be great! :slight_smile:

Hi all,

I’d suggest looking at the custom locale plugin – https://github.com/asmecher/customLocale – as it’s intended to override existing locale keys with its own.

Alec Smecher
Public Knowledge Project Team