Github action to automatically update list of all lanuage files and contributors

[Zkir]

When a new brunch for a new version ( even a minor/patch one) is created, previously existing translations are lost.

For example, there are just 3 translation (as of 2024-08-05) in v2.22.2, but there were 7 of them in v2.20.0 including ru and uk.

I translated all the lines into Russian before I realized that this translation had already existed.
A guy who wants a Russian translation for 2.22.3 will probably translate it all over again.

Note, that Contributors list for the previous versions is also empty, despite translations existed.

I guess language files should be somehow inherited from the previous version, even incomplete/obsolete ones.
Obviously, if an original line is changed, corresponding translated line should be cleared up.

[blablubbabc]

previously existing translations are lost.

They are not lost. As described in the Readme, each version gets its own branch. As a user of these language files, you can think of these as separate directories, each containing the language files for a particular plugin version.

I guess language files should be somehow inherited from the previous version, even incomplete/obsolete ones.

Each version branch should only contain runnable and fully translated language files for that version. If there are changes required from one version to the next, it would be confusing for users of those language files to find language files that are not actually compatible with their desired plugin version.

I agree that the repository structure of separating the translations for different plugin versions into different branches (rather than for example different folders) makes the discoverability of previous language files a bit more difficulty. For plugin users, it is quite simple to select the version they are interested in and then find all the language files available for that version. But for translators, it is inconvenient having to search through all past branches to find the last translation for their language. Unfortunately, Github doesn't seems to offer a way to also search other branches for files.
Edit: Actually, Github includes commit messages in its search results, so it is possible to find find previous commits mentioning a particular language. But still not as convenient as it could be.

However, the repository was explicitly changed to this structure (it was different in the beginning) to simplify the updating of language files from one version to the next: It is quite easy to view the history and differences of files between different versions / branches directly on Github (e.g. 54bf095#diff-5362bae55e2c64449d2ae0d0b95129da5eb035b538ea8ee62fd568a0a55aef89). But there is no easy way to view the differences of files located at different paths / folders.

Regarding the contributors lists: There are links to the contributor files for each version. Inheriting/Copying over the list of contributors of previous versions into the contributors file for the current branch would make maintenance worse: Whenever there are changes to the contributors in a previous version (each branch/version can evolve separately), one would also need to update the contributor lists in the all of the subsequent versions/branches to mention them there as well. So instead of doing that, or having outdated contributor lists, I chose to only list the contributors for the current version and instead link to the always up-to-date contributor files for all the previous versions.

If you have any other ideas that fulfill the following criteria, let me know:

• Easy for langage file users to find compatible/working language files for their version. Not only for the latest plugin version, but also for any previous version. No additional steps required other than downloading the file any placing it inside the plugin folder (i.e. no file renaming, testing, etc.).
• Easy file differences directly on Github from one version to the next.
• No additional maintenance effort, e.g. no updating of lists/indexes in later branches whenever there are changes/additions for older versions.

[Zkir]

@blablubbabc thank you very much for such a detailed answer.

I do not have any particular advice how to reorganize this github repository, maybe it is not necessary at all.
However, I've managed to create a very simple python script which prints some kind of pivot table to see all the translations from different branches on a single page and understand their completeness.

Here it is:

Language	Version	Completeness	Missing	Obsolete	Extra	Link
de	v2.22.2	100%	0	0	0	language-de.yml
es	v2.22.2	100%	0	0	0	language-es.yml
fr	v2.22.2	100%	0	0	0	language-fr.yml
ru	v2.22.2	100%	0	0	0	language-ru.yml
cs	v2.20.0	97%	11	0	0	language-cs.yml
pl	v2.20.0	97%	11	0	0	language-pl.yml
uk	v2.20.0	97%	11	0	0	language-uk.yml
zh_CN	v2.20.0	97%	11	0	0	language-zh_CN.yml
pt-BR	v2.19.0	96%	14	0	0	language-pt-BR.yml
sk	v2.19.0	96%	14	0	0	language-sk.yml
tr	v2.19.0	96%	14	0	0	language-tr.yml
zh_TW	v2.19.0	96%	14	0	0	language-zh_TW.yml
ua	v2.17.0	94%	23	0	0	language-ua.yml
zh-CN	v2.17.0	94%	23	0	0	language-zh-CN.yml
es-419	v2.13.2	70%	115	6	4	language-es-419.yml
ja	v2.13.2	70%	115	6	4	language-ja.yml
es-419-2	v2.11.0	0%	409	0	220	language-es-419-2.yml
it	v2.11.0	0%	409	0	220	language-it.yml

The table displays the most recent plugin version for which a translation into particular language exists, and compares it with the current language-en-default.yml file, thus indicating the amount of efforts necessary to update the translation to the current plugin version. (If you like, I can add the check for missing placeholders/color codes.)

We can see that UK and UA are two completely different translations into Ukrainian language, and the same thing with Chinese translations: zh_CN , zh-CN . So it's not only myself so stupid, other translators also fail to find existing translations.

You can use this script as you like, to make it more easy to find translations for your contributors. :)
Maybe it would make sense to put this table into TRANSLATIONS.md in the root of the repository and update it when a new translation comes in.

[blablubbabc]

Maybe it would make sense to put this table into TRANSLATIONS.md in the root of the repository and update it when a new translation comes in.

Maybe an option could be to have a build action on Github automatically update an index file on the current main branch whenever there are some changes in any branch.

[hhhhh-ckr]

I love this idea and it would really help, is there anything we can do?