DRY-RUN: Test release process for r3.8.0 po4a and smaller changes #579

jamulussoftware / jamuluswebsite

This is the GitHub Pages repository for the Jamulus main website. For the jamulus application source code, please visit jamulussoftware/jamulus.

https://jamulus.io

GNU Lesser General Public License v2.1

15 stars 82 forks source link

DRY-RUN: Test release process for r3.8.0 po4a and smaller changes #579 #580

Closed ann0see closed 3 years ago

ann0see commented 3 years ago

As proposed by @ignotus666 we're doing a test translation round for the po4a workflow. This issue should focus on all the discussion around the process.

ann0see commented 3 years ago

@ignotus666 commenting here

Translations get merged into next-release; next-release is frozen until this one is merged. But I think we still need an OK by @gilgongo to ensure nothing unfinished/for r3.8.1 gets released

ignotus666 commented 3 years ago

Ok, I get it.

gilgongo commented 3 years ago

Not sure how I would determine that though. The docs I did for the next release I don't think had anything that would relate to anything here is that what you mean?

ann0see commented 3 years ago

Yes. If we added content for 3.8.1 this should be removed. If not, we can start the process. See https://github.com/jamulussoftware/jamulus/milestone/4

gilgongo commented 3 years ago

What about these? https://github.com/jamulussoftware/jamuluswebsite/milestone/3

ann0see commented 3 years ago

I think the current status of them is ok too.

ignotus666 commented 3 years ago

If possible, I'd go through the different processes to see if they work (create a checklist?) and to get familiar with them.

Preferably in this order to avoid disrupting any potential translation process:

Edit/add EN content in wiki/en/ (next-release). Check that it shows up in the .po files.
Make a correction to an EN doc in release and validate the corresponding segment in (translated; no need if they're not) .po files. Verify that the sync with next-release works without conflicts.
Optional: add a language (Chinese? maybe the person who did the app translation can be approached - a single test file would be enough).
Translation of .po files. I have translation memories that may come in handy, particularly for FR as it has the most translated content.

ann0see commented 3 years ago

Yes. You should document the process somewhere ;-). I‘ve already opened #579 which will show all the differences between next-release and release. Later on this will need to be merged to put all stuff live.

Concerning the new language, maybe try to go through the process yourself and later remove the language.

ann0see commented 3 years ago

CC: @jamulussoftware/translators

You might want to monitor this issue since it‘s related to translation. There’s no need to start the translation process now, however I think it’s good if you’re aware that we try to test the new po4a translation workflow.

ignotus666 commented 3 years ago

You should document the process somewhere ;-)

Well, from the point of view of editing EN content, not much has changed. However, it is documented in /wiki/README. The translation process is documented in _translator-files/README.

I‘ve already opened #579 which will show all the differences between next-release and release

Is there a particular reason why we need to see the differences? It's not needed by translators in any event.

ignotus666 commented 3 years ago

It's not needed by translators in any event.

At least not anything in /wiki/en/. Changes to other documents not covered by po4a that need translation, e.g. in _data, 1-index.html etc. will need to be documented somewhere so translators are aware they need to update their translations. A future enhancement might be to somehow process these files with po4a too.

ann0see commented 3 years ago

Yes. By documentation I mean the process we‘re doing to release the repo should be part of a checklist:

[ ] Open a pull request from release to next-release and set it to draft
[ ] Mention all translators and point them to changes not part of the .po files
[ ] Wait until translations arrive
[ ] Review each translation PR etc. Similar to the release checklist by hoffie: https://github.com/jamulussoftware/jamulus/blob/644f1c7653bcec09ee6854f0826b5ea14870cf8d/.github/ISSUE_TEMPLATE/release_new_version.md

ann0see commented 3 years ago

Is there a particular reason why we need to see the differences? It's not needed by translators in any event.

No, but at one point we need to merge next-release into release. If a draft PR is already open, reviewing is easier. At one point once we click on merge, the site goes online.

ignotus666 commented 3 years ago

I think I've figured out how to also process with po4a the files in _data and _includes, and also the index.html files, using symlinks. It would mean the status for all translatable docs could be in the "Statistics" file for consultation, removing the need to document changes to these files.

ignotus666 commented 3 years ago

I've decided against it. Po4a does a sloppy job of segmenting these files (1 or 2 giant segments in most cases), and any change in their EN counterparts causing the templates to update would wipe out practically the entire translation -> not good.

ignotus666 commented 3 years ago

What I will be doing is getting rid of the wrapping in the .po files - it causes an utter mess in PRs every time someone opens them in a different editor and it doesn't offer any benefits other than just looking tidier when reading the raw .po file. It's also been mentioned as a cause of git conflicts, so it's going (with the --wrap-po no option). This means translations shouldn't start yet as it will take some work to do the switch (make sure all translations are stored in TMs, re-create .po files without wrapping and re-populate them with translations).