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?
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.)
Public Knowledge Project Team
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?
The custom locale plugin exists for OJS3, but it’s not complete/released yet. If you’d like to experiment, have a look at https://github.com/asmecher/customLocale. 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?
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
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!