Improve Release Process / Weblate integration

[pljones]

What is the current behaviour and why should it be changed?

The current release process documentation makes little reference to how either app or website documentation is managed through Weblate, or how a someone handling the release process can check who has been making changes to a translation on Weblate (or, indeed, directly via git).

Describe possible approaches

Ideally, the tooling would be able to maintain the current Weblate translators without intervention and we would require that a translator had a visible Github identity associated with the Weblate (or git) contributions.

In any case, improved documentation on how translations work is needed or needs to be referened with clear guidance in the release process documentation.

Has this feature been discussed and generally agreed?

Raised concerns over in #3126. Closing that issue based on raising this.

[ann0see]

@ignotus666 knows more about the Weblate process. I think the mess was created by the website having conflicts.

[ann0see]

we would require that a translator had a visible Github identity associated with the Weblate (or git) contributions.

Unfortunately this isn't possible. Everyone with a weblate account can make changes to that. Therefore the Weblate PRs should be checked by the translators.

[pljones]

Therefore the Weblate PRs should be checked by the translators.

...who would be required to have visible Github identities, so they could sign off their check by closing the raised issue.

[ann0see]

Kind of. Yes. But there are no guarantees that that's the case.

[pljones]

What I'm saying is that there's no point us raising the current issues unless that is guaranteed to be the case. So either we change policy to require it or we drop creating the issues at all and just rely on Weblate. There's no point trying to maintain something inherently broken.

[ann0see]

The issues are for notifying translators to start translating. Maybe we can condense it to one issue which pings all translators. That reduces complexity

[pljones]

If the translation is being managed through Weblate, we should have a way on Weblate of notifying the translators. The Github management shouldn't be related.

[ann0see]

Weblate does have a notification system and I did use it to notify the translators.

However, there might be translators who are on GitHub and Weblate.

Discussing the translation process is inconvenient on Weblate in my opinion.

I think @jamulussoftware/translators should judge how we handle translation in future.

[pljones]

Converted to a discussion until we have something that can be actioned.

[ann0see]

I think we should revisit this after the release got out.

[ann0see]

Ok. One thing: https://hosted.weblate.org/projects/jamulus/#reports shows the translators in a given timeframe. I think this should be added to the documentation.

[pljones]

It's also possible to add a per-language link to the app tickets. (Trickier for the website, as it's multiple Weblate components - there may be a query syntax for "everything except the app", I didn't check.)

e.g.

Progress: https://hosted.weblate.org/changes/browse/jamulus/jamulus-app/sv_SE/?start_date=2023-07-30

[ann0see]

Ok. @ignotus666 @comradekingu (as you know Weblate)

@pljones Can we make a list for what needs to be done here?
I believe:

1. The release checklist must be updated - e.g what do we need to do on Weblate?
2. The translator tooling (create translation issues, change log script,...) needs to be updated: Use the Weblate API
3. Documentation for the website needs to be updated and added

[ann0see]

TRANSLATING.md: I thought that we needed to update the Translation for Translators too, not sure if it's good enough at the moment? Can some translator comment on that?
Checklist: Agree. Do you have a specific issue we can fix?

[pljones]

• For each supported platform, there should be a clearly documented process of how to build and package the installer. This isn't currently the case.
  Reason: Should we need to switch from Github at a time when the existing workflows are no longer understood by anyone on the team, having a clear explanation of what needs doing will ease migration.

  • This need not be in Release-Process.md but there should be links there so the documentation is easily found.
  • In addition, the differences in building final, release candidate, beta and development builds should be documented somewhere, too, along with how those affect the tooling.

• We need to be clear about when lrelease should be run -- should new translation files be included with a PR, or should we postpone all translation file generation until the release?
  I'd favour iterative development, myself -- but then, I'm not a translator: I just want Jamulus to be ready for release on PR merge 😄.

• The issue template for the release and Release-Process.md need reviewing to make sure they're in agreement.

  • For example, "Notify all the translators that translation is required" in Release-Process.md should also mention updating the script with current translators (if we're going to continue using it).

• The checklist for translations isn't clear: for example, "Punctuation and spacing consistent" - this should reference some guideline documentation.

• We may want to review the SourceForge processes in the light of recent discoveries.

• The whole of the website section needs reviewing by someone who knows the processes.

• The announcement template could be a Github issue template

  • I also don't like the layout - the one we used for this release was nicer, so it could do with Release-Process.md being updated.

• Speaking of issue template layouts, I like the planned dates in the "Prepare Release <rel>" issue tabular, too (like the current one).

• The ChangeLog generator seems to "generally work" - if there are common points where "manual assistance is require", we should aim to capture them -- I think that might be worth adding to the Release-Process.md section about using the script.

[ann0see]

Thank you! This sounds like a good list.

[ann0see]

We may want to review the SourceForge processes in the light of recent discoveries.

I believe we can only test that if we do a release.

The whole of the website section needs reviewing by someone who knows the processes.

Which leaves me, @ignotus666 and @gilgongo

The announcement template could be a Github issue template

We had this discussion already, but it might confuse people who open an issue.

The ChangeLog generator seems to "generally work" - if there are common points where "manual assistance is require", we should aim to capture them -- I think that might be worth adding to the Release-Process.md section about using the script.

Agree. Not sure if we can count on hoffie being available.

[pljones]

We had this discussion already, but it might confuse people who open an issue.

Mmm... I don't think the template's current location is ideal, though.

[jujudusud]

I had this discussion comment in the release retrospective.
What do you think about this point of view ?