Hi, we worked on our OJS 3.3.0-13 to complete the .po translation files because some labels were missing.
We checked all the .po file in both \locale\it_IT and \lib\pkp\locale\it_IT, comparing them to en_US and then uploaded the resulting updated .po files in our installation. We worked offline because in weblate it results to me that only the last version of translation - related to the release not already published - is available.
Is this the correct way to work on a specific release?
I’m writing to understand how to share our work: I thought to present our .po files in github as pull request for the release, but I found that there is only a 3.3.0, so I checked the corresponding .po files and they look the same as amount of labels, but - don’t know why - listed in a different order… So, I preferred ask here how to proceed instead taking the risk to open a pull request for the wrong release.
Best regards
Stefano
HI @bolelligallevi,
Thanks for your post and for being willing to contribute to translations. I was looking at our translations guide, and I don’t know that it mentions working within specific releases and how this is differentiated (https://docs.pkp.sfu.ca/translating-guide/en/translate-software). It’s a good point - @asmecher - any thoughts on this?
-Roger
PKP Team
Hi @bolelligallevi,
The difficulty in moving translations between different versions, and the need to choose a single branch for contributions from Weblate, has been a thorn in our side for a while. We’ve been working on what’s called a “translation summiting” workflow, similar to what’s beautifully documented in the KDE project translation workflow. There are two stages for adoption of this process:
- Setting up the summiting tools and cleaning up the locale files for their use. This permits us to port translations back from
main (which will soon be released as 3.4) to stable-3_3_0 (for 3.3.0-x releases), though in an incomplete form. We are currently at this stage – the tools are on Github, and we’ve tried back-porting one translation (zh_TW) with success. However, the back-ports to 3.3.0-x will be incomplete. They will not include locale keys that only appear in stable-3_3_0 but not main, nor will they contain local keys whose meanings have changed between the two branches (e.g. most of the email templates).
- Adopting a complete locale summiting workflow, where the translation tools (Weblate) work on a summited set of locale files that is separate from any one branch of the software. This will require significant changes to our development process, and some additional overhead, so we won’t be able to try this out until after 3.4.0 is released. But longer term, I hope this will make it transparent for translators; they will be able to translate using Weblate (or their own tools) and the summit tools will take care of applying those translations to any relevant branch.
If you’ve got a translation to contribute to 3.3.0-x separately from this process, you can open a pull request against the stable-3_3_0 branch in Github and I’d be happy to take a look. Beware that we try not to introduce any “breaking” changes to 3.3.0-x, though, so please try not to disturb existing translations!
(This has been a tricky problem to solve and I’m surprised there aren’t more documented workflows! If anyone is aware of others, I’d welcome the input on the linked discussion.)
Thanks,
Alec Smecher
Public Knowledge Project Team
3 Likes