Add GitHub Action to track doc-en merged PRs

[lacatoire]

Summary

• Daily workflow (6h UTC) that checks the last 7 days of merged PRs in php/doc-en and creates issues in doc-pt_br listing the PT_BR files that need updating
• Stateless deduplication via issue search (no duplicate issues)
• Skips [skip-revcheck] PRs automatically

Inspired by php/doc-fr#2479

[alfsb]

• Daily workflow (6h UTC) that checks the last 7 days of merged PRs in php/doc-en and creates issues in doc-pt_br listing the PT_BR files that need updating

To consider. Instead of creating many issues for each merge on doc-en, create at most one issue on translations, and mutate it with the listing of the updated result of script. So:

• If there is a sequence of doc-en merges that affect the same file, this outdated file name appears only once;
• If the issue gets big with many comments, translations can close it, and a new clean one is opened;
• Having issues and listed files having a N:N relation, these unconsolidated lists of outdated files are very hard to coordinate.

• Stateless deduplication via issue search (no duplicate issues)

As above, the problem may not be due to duplication of issues, but the duplication of file names in many issues.

• Skips [skip-revcheck] PRs automatically

There is a problem in [skip-revcheck] position in messages. In modern usage, [skip-revcheck] in the start of commit messages is always correct, and [skip-revcheck] in the middle of commit messages is always wrong. For example, when a reversion includes the messages of reverted commits, some messages containing [skip-revcheck], then all reversion get skipped, that is wrong.

There exists php/doc-base#181 , that was not merged until now because this change is not unanimous.

---

I can change the doc-base/scripts/translation/configure.php to generate a file named doc-base/temp/translation.need.sync, with the listing of files needing translations. So this script can be simplified to running this configure.php, check if the file was created or not, and if it was created, then mutating or opening an issue with the file contents.

Or better yet. I can change doc-base/scripts/revcheck.php to create this file, so the the script sub runs doc-base/configure.php and doc-base/scripts/revcheck.php, checks for failures of both and the file creation to mutate or open a fixed issue, containing:

1. The output of these scripts, if they failed;
2. The contents of translation.need.sync if translation.need.sync was created;
3. Or better yet, the contents of revcheck.html or an iframe https://doc.php.net/revcheck.php , instead of the simple file listing.

[alfsb]

Agora entre a gente. O que vocês preferem. Um issue por merge no doc-en? Um issue único, aberto ou atualizado quando os scripts falham ou geram lista de arquivos desatualziados?

De minha parte eu acharia mais útil o segundo caso, com um link e um iframe apontado para o doc.php.net/revcheck.php.

[leonardolara]

Agora entre a gente. O que vocês preferem. Um issue por merge no doc-en? Um issue único, aberto ou atualizado quando os scripts falham ou geram lista de arquivos desatualziados?

De minha parte eu acharia mais útil o segundo caso, com um link e um iframe apontado para o doc.php.net/revcheck.php.

Na minha humilde e sincera opinião, esse script é desnecesário. Esse controle do que está desatualizado já é feito pelo revcheck na web. Além disso, aumenta o trabalho ter que ficar fechando cada item.
Não trato a falta de tradução como um issue. Os issues, ao meu ver, são aqueles problemas de tradução.

[alfsb]

Na minha humilde e sincera opinião, esse script é desnecesário. Esse controle do que está desatualizado já é feito pelo revcheck na web. Além disso, aumenta o trabalho ter que ficar fechando cada item. Não trato a falta de tradução como um issue. Os issues, ao meu ver, são aqueles problemas de tradução.

Eu também acredito que arquivos desatualizados não devam gerar issues, no caso de traduções que sejam bem mantidas (que é o caso da tradução brasileira, graças ao seus esforços aliás). Eu estava pensando na situação bem anterior, quando a tradução brasileira era parecida com algumas outras, quando as atualizações eram esporádicas e dependiam do email do build semanal para saber que alguma coisa tinha dado errado, e o manual não estava mais compilando, atualizado ou não.

De qualquer jeito esse issue não serve para o nosso caso, e vou fechar sem merge. Mas de qualquer forma, eu queria aproveitar esse código para usar como base de "reconstruir" o build automatizado + notificação, na forma de issue, e daí disponibilizar a todas as traduções, que daí escolheriam usar ou não. Na tradução em português do Brasil, que é bem mantida, isso seria desnecessário, e daí desativado.

[alfsb]

@lacatoire , I'm closing this PR without merging as doc-pt_br is a well maintained translation that checks outdated and new files based on web revcheck (there is also a local revcheck).

But the old, weekly automatic build log via email is deeply missed for translations with less active teams. A version of this code, that opens or updates a unique issue reporting broken manual builds or outdated files, as outlined above, would somewhat recreate this lost functionality.