Addons template.pot for the current Gramps version

[kulath]

As I understand it, Weblate for addons (weblate:weblate-gramps-project-addons) is moved from gramps60 to gramps 61 at the same time as the weblate for the main gramps is moved to gramps61.

However, this does not work for two situations:

1. Where a new addon is created during the currency of the current Gramps version (in this case Gramps 60).
2. Where there are new translatable strings that appear for old addons where the author did not also update template.pot. There are apparently 22 of these (see Update template.pot for 6.1 addons-source#831). I appreciate that ideally this is just a one off, but the ideal does not always apply.

In both cases, new translations for existing addons for the current Gramps release will not exist.

It seems to me that it is not appropriate to abandon translating the addons for the current Gramps as soon as the main Gramps is moved to a new version.

I am not sure I fully understand the translation workflow, so forgive me, but would it be possible for make.py aggregate-pot to merge strings both from the current Gramps addon and the future one, and then to update from Weblate to xx-local.po for both the current and the future Gramps addon? Presumably the packaged addons would also have to be updated, and I can see that it would not be helpful to bump all the versions for an addon that a user was not using in a language that the user was not using, so I suppose it might be necessary to update the xx-local.po without changing the version of the addon (except in case 2. above).

This may be slightly related to #2311, but I would appreciate it if it could be addressed separately and soon!

[jralls]

@kulath,

The translation workflow is:
A maintainer (usually @Nick-Hall for gramps itself and @GaryGriffin for addons) generates a new pot-file from the translatable strings in the source code, merges that new pot-file into the po files, and commits the result. Weblate reads the commit and updates its database. The pot-file and resulting po files represent a single state in the repository: Deleted strings (msgids) are also deleted from the pot-file and therefore the po files; changed strings are changed and marked fuzzy to flag translators that they need to be reviewed.

Over time translators modify the translations in Weblate. Weblate creates a pull request (e.g. addons-source:#888. It pushes more translations as they occur.

From time to time the maintainer merges the translation PR. When Weblate has more translations it opens a new PR.

From time to time the maintainer makes a new release of Gramps or Addons. Part of the build is compiling the po files into message catalogs (foo.mo) that gettext actually uses to retrieve the translated strings. This is the point that users (aside from the very few who build Gramps or the addons from git) get the new translations.

[Nick-Hall]

The additional steps for the addons-source repository are:

After a template.pot file has been changed, the aggregate-pot script is run which aggregates all template.pot files into a single po/addons.pot file. Strings that are already in gramps.pot are excluded.

After a Weblate PR has been merged, the extract-po script is run which extracts strings from the aggregated po/{lang}.po files into the {lang}-local.po files for each addon. The addons are the built as usual with incremented versions. This will mean that users will get updates for languages that they don't use.

Weblate is only used to translate the current maintenance branch.

[kulath]

Thanks for the explanation, however, I don't think it addresses the point I was trying to make, sorry I wasn't clear.

@jralls From time to time the maintainer makes a new release of . . . Addons

@Nick-Hall After a Weblate PR has been merged, the extract-po script is run which extracts strings from the aggregated po/{lang}.po files into the {lang}-local.po files for each addon. The addons are the built as usual with incremented versions. This will mean that users will get updates for languages that they don't use.

I don't think that this happens for addons. @GaryGriffin can perhaps confirm this. As far as I can see, the packaging is only done when a change is made to an addon, and then only for that specific addon. This is to prevent users being prompted to update their addon when perhaps only a language they are not interested in has changed.

@Nick-Hall Weblate is only used to translate the current maintenance branch.

Weblate for addons has already been moved to refer to Gramps61, which is not the current maintenance branch, but the next version.

The net result is that AIUI, if a new addon is created for the current branch, strings in template.pot are merged into Weblate, translated and extracted into {lang}-local.po, but packaging is not done. So, even if the current branch is being updated by Weblate, the translated strings will never be seen by users (unless an unrelated change is made to the addon).

As @GaryGriffin says in a private message:

kulath:
However, it does lead to the anomalous situation that if an addon is published, and never updated by a PR, then the translations for that addon will never be issued.

I wonder whether something could be done to alleviate this situation?

Gary:
Yes, this is a balancing act between too many updates and stale translation. The current process started with 6.0, so I think we are still learning how to balance.

I suggest two changes:
(1) would it be possible for make.py aggregate-pot to merge strings both from the current Gramps addon and the future one, and then to update from Weblate to xx-local.po for both the current and the future Gramps addon?

(2) Periodically re-package addons where the only change is translations, but without incrementing the version, so users do not get prompted to update their addon unecessarily.

[Nick-Hall]

Weblate for addons has already been moved to refer to Gramps61, which is not the current maintenance branch, but the next version.

Correct. We create the maintenance branches for both core and addons a few months before release and switch Weblate over at the same time. This gives translators time to translate the new strings.

I tend to refer to gramps61 as the current maintenance branch in core because gramps60 is closed. There will not be a v6.0.9 released.

[Nick-Hall]

would it be possible for make.py aggregate-pot to merge strings both from the current Gramps addon and the future one, and then to update from Weblate to xx-local.po for both the current and the future Gramps addon?

Yes. You could merge the aggregated addons.pot file from one branch into another. I don't recommend this because it would probably create confusing file references. A better approach would be to create a new Weblate translation component with just the differences between the branches.

[GaryGriffin]

I don't think that this happens for addons. @GaryGriffin can perhaps confirm this. As far as I can see, the packaging is only done when a change is made to an addon, and then only for that specific addon. This is to prevent users being prompted to update their addon when perhaps only a language they are not interested in has changed.

That is correct, I do NOT remake all addons when I run extract-po. Maybe I am doing this wrong.

The lifecycle of a language change for a string change. If I misunderstood what I should be doing, plz let me know:

1. template.pot changes (Gary running make.py init, or seeing developer including a template.pot in the PR.
2. make.py aggregate-pot to collect all strings and send to Weblate. This is done on gramps61 only
3. Weblate user makes change
4. At some arbitrary time (like a month since the last one), make.py extract-po
5. At this point, all the Addons have all xx-local.po updated in git but it has not been released.
6. If an Addon has a PR against it, it is repackaged with the updated translations and published. Otherwise, the only way the user will see the revised translation is if they build from repo.

I suggest two changes:
(1) would it be possible for make.py aggregate-pot to merge strings both from the current Gramps addon and the future one, and then to update from Weblate to xx-local.po for both the current and the future Gramps addon?

(2) Periodically re-package addons where the only change is translations, but without incrementing the version, so users do not get prompted to update their addon unecessarily.

The current process to repackage (make.py build) creates the download tgz AND increments the version. I cannot remake the tgz without the version change. And even if I could, it wouldn't help since the Addon Manager would not see the change to notify user to update.

The last time I updated the translations (last week), I also cherry picked the xx-local.po files to gramps60 since there were no Addons that had string differences yet between gramps60 and gramps61. I have also updated at least 30 Addons (both branches) last week while processing lint PRs, so those Addons should have translation updates on both branch releases.

I am happy to update my process if I misunderstood it.

[Nick-Hall]

At this point, all the Addons have all xx-local.po updated in git but it has not been released.

You can rebuild and release addons with just translation changes.

[GaryGriffin]

When I reviewed the last week merge after running extract-po that updated the xx-local.po, 100% of the Addons had a language change. I dont know if that is normal or not for monthly changes in Weblate. Lets assume that it is not unusual.

So in this case, should I make.py build as-needed ; make.py listing all after running the monthly make.py extract-po ?

If the impact is significantly less, then should I build the specific addons impacted?