Is it possible to keep translate personalization?

I have three journals with independent OJS installations, each Editor has some differences in how to say some things and they want to make personalized emails, for this I have been some changes in XML files, but if I update I need review manually for review if some strings are new and then I make this changes in my files.

In other systems, I have the possibilities to make a file only with the string I want to change and this replaces the original string. Is implemented something like that in OJS?

Hi @t4x0n,

There are three options to consider…

  • Continuing to make modifications, and using diff to extract the modifications before upgrading. If you plan to make any modifications beyond the locale files, this is a good idea anyway.
  • Using a tool like git to manage changes.
  • Use the custom locale plugin to selectively change locale keys. (This applies on a per-journal basis, not system wide.)

Alec Smecher
Public Knowledge Project Team

Hi @asmecher,

Thanks for your reply, as I do not have a lot experience in Linux I didn’t know about diff (I read about it just now) and git is good too but not my favorite option, both option sounds good but I am thinking in one more easy option. This plugin that you mentioned in the third point is available for OJS 3?

Really I am starting to think in another option:
Using as base the Spanish translation, I am thinking in make my own translation like es_CL Español (Chile) or es_LA (Latinoamérica). With this method I can use some different way to say something (more like Latin American or Chilean style).

If I follow this option, are you interested in include this new translation in your repo in GitHub?

Hi @t4x0n,

The custom locale plugin exists for OJS3, but it’s not complete/released yet. If you’d like to experiment, have a look at The update to 3.x was done by LangSci Press; this link is my fork of it, with a few changes.

I’m hesitant to add another translation unless we have a sense it’ll be useful to others, receive somewhat regular maintenance, and not detract from the existing translation (e.g. by splitting the user community in half). I’m a poor Spanish speaker, so I’m not sure how deep the changes between Spanish translations would run. Perhaps @marc has an opinion?

Alec Smecher
Public Knowledge Project Team


From the 3 methods suggested by Alec here I encourage you to use the third one. Keeping control over the changes based on diff even with git it’s a lot of work because in every version you will need to replace es_ES files with your own modified ones, but with the “custom locale” plugin you can keep your translations between versions.

In the other hand, I like the idea of an es_CL (I think don’t make sense a “es_LA” because there are a lot of dialectal variations) so people can decide the version he/she like most, but as Alec said it means translating everything now… but also assume an upgrade task in future.

So in short, if @t4x0n feels he can do it, I’m ok with a es_CL variation.


Hi marc, how can i help you with that? meaning, unless this can be done over docker image. Whats your thought?


My fault @lucasdiedrich, forget it…
I was writing two post at the same time and I mixed them :smiley:
I wanted to mention @t4x0n

I edit former post to clarify.

Thank you @marc and @asmecher,

An es_CL is not a bad idea but at this moment is not exist a uniformity about how to say some editorial things even between Chilean editors, so in the future… I hope can make that and only if this is really necessary.

For now, maybe the custom locale plugin is the solution!


1 Like