Theme Options API: localised

First of all I have to say that the new theming possibilities, especially the Child themes and the theme options are excellent!

However, I was hoping to see that addOption/getOption values could be localised. This would be great especially for the text fields. But as I am writing this I started thinking that having localised typography would not be a bad idea either.

For the text fields I thought that this would be an easy thing to change, but I see now that the plugin_settings table does not have a field for that.

Any thoughts?

That’s a good question. I presume you want multi-lingual input for a site that can be viewed in multiple languages. We haven’t used a text field yet so we haven’t really encountered this.

We’ll probably want some facility for this in the future, but since it’s not really important for select or color fields, it’s not likely to be a priority unless we see a real use-case for it. Do you have a custom theme in development for which you want to add a text theme option?

I already have a theme ready. I use the feature to define a subtitle for the journal name. Basically I have two fields the main title and the subtitle. This way I do not mess with the journal metadata.

Ah yeah I see. I definitely think this is something we’ll support down the line. But you’re on quite a tight deadline now, right?

I might advise you to look into handling the custom journal titles and subtitles as data in the journal_settings database. Have you extended one of our Form objects through a plugin before? Take a look at the HookRegistry::call( instances in

These will help you add a new piece of data (journal_subtitle), initialize it in the form, and store it in the database. The actual form I’d recommend extending is

And you’d need to override the appearance settings form template to add your custom field:

So there are quite a few more steps. But I think we probably won’t get multilingual theme settings in place in time for your needs.

Thanks you for the detailed answer. I will probably solve this now by using custom locale files in the child theme. I will create two new locale keys for the titles and then just load the needed language versions.

However, getting this kinds of options to the database would be nice.

Good idea with the locale files! I think OJS 2 had a locale string editor plugin which allowed you to edit any locale string through a web-based interface. That would work well for these kinds of things in the future too.

Hi all,

There’s the Custom Locale plugin, which is working for OJS 3.0.1 and OMP 1.2+:

I haven’t finalized this for release, and its interface is a little clunky, but it’s something to start with.

It’s originally work done by the Free University of Berlin, all credit to them!

Alec Smecher
Public Knowledge Project Team


Have tested this with OJS?

Hi @ajnyga,

It works with OJS, but it’ll use the pathname “presses” for its own storage. This is one of the things I have to resolve before formally releasing the plugin.

Alec Smecher
Public Knowledge Project Team

Good to know, thank you!

Hi Alec,

we would need this plugin to upgrade our biggest OJS instance to OJS 3.1.1 .

Do you think it is a lot of effort to make it work with 3.1.1+?
I’ll have to check with my boss, but maybe we have time to do it, because we will definetly need it for the OJS 3 migration this year.


Hi @nweiher,

Do you mean the Custom Locale plugin? I haven’t tested it with 3.1.1 specifically, but if it’s not working, it’ll be trivial to fix. Note that it’s not totally “complete”, strictly speaking, because of some of its UI elements – but it is usable. Let me know if you get stuck.

Alec Smecher
Public Knowledge Project Team