I'm always hesitant to apply such changes without notifying the
translators. I am, however, to lazy to file issues (let alone PRs) to
all active translations (currently about 10). I also don't want to ping
a couple of active translators; they just may not have time to respond,
and keeping such a list up-to-date is probably not that easy.
So I thought that maybe there should be a Github workflow to automate
this. Perhaps just automatically open issues for all active
translations, maybe something like:
Breaking change for translations
We are going to merge php/doc-base#12345, which may break your
translation. See php/doc-en#23456 how to fix this.
Or even send automated PRs (probably pretty hard).
Now I don't know how that would be feasible, but apparently there are
some available Github actions which could handle that.
What do you think about this? Does anybody has experience with such
workflows? Or am I thinking too big, and there is already an easier way?
perhaps for such PRs, it could be possible to provide an automatic approve request
from active translators (or php/doc-<lang>-team teams),
but not always changes to doc-base break all the translations,
for example if there are few translated files in the translation repository, and these changes don’t affect them.
Perhaps we can make it so that only teams that have a broken build are asked for approval…
But IMO, when a build is broken, an email is sent to the language mailing list about it [1],
and active translations fix it promptly.
On Wed, Aug 7, 2024 at 6:15 PM Christoph M. Becker <cmbecker69@gmx.de> wrote:
So I thought that maybe there should be a Github workflow to automate
this. Perhaps just automatically open issues for all active
translations, maybe something like:
Sending a short email in this mail list, as exemplified, pinging of
some imminent intentional doc-en/doc-base breakage is sufficient. All
editors in all languages are (still?) required to be subscribed here.
Perhaps this requirement should also apply to watching doc-base repo
in GitHub. This is now the place where all languages converge, because
of the compilation tools. Opening an issue there can replace opening
multiple issues in each language repository.
I'm always hesitant to apply such changes without notifying the
translators. I am, however, to lazy to file issues (let alone PRs) to
all active translations (currently about 10). I also don't want to ping
a couple of active translators; they just may not have time to respond,
and keeping such a list up-to-date is probably not that easy.
Having tried to make the removal of the XForms-related documentation as gentle as possible for translations, I think in hindsight it's not really worth worrying about too much as long as the change is fairly mechanical in nature and not something that will require any significant translation work.
The build of the language from before the doc-base change lands will just remain the most recent version until the translation is caught up to changes in doc-base, and if someone is taking the time to merge in new translation work, they should be able to resolve the build issue as well.
I submitted PRs for all of the translations because it was a simple change, which I think is a nice thing to do, but I don't know that it should be required.