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?
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.)
Regards,
Alec Smecher
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?
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?
Regards,
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.
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!