Ideas about a gtksourceview-data repository
The *.lang files are present in the main GtkSourceView git repository.
New *.lang files are available only for GtkSourceView 4, to not add new translatable strings in GtkSourceView 3.24, although new *.lang files would be suitable for GtkSourceView 3 as well because the XML format is the same.
Central maintenance problem: once a *.lang file is accepted upstream, the original author usually disappears and we (the GtkSourceView maintainers) need to deal with bug reports, patches, etc for languages that we know nothing about.
Solution 1 - lots of small git repos
Decouple *.lang files from the main GtkSourceView repository, by creating a repository named for example gtksourceview-data.
gtksourceview-data could also contain style schemes.
The data files in gtksourceview-data would be usable for GtkSourceView 3, 4, 5, … as long as the XML formats are compatible.
- Question: what to do when the XML format evolves?
- Maintenance decentralization: instead of having all the *.lang files in the same repo with only a few maintainers, have roughly one git repo per *.lang file, with ideally the original author maintaining his/her repo. In some cases it would make sense to group several related *.lang files in the same repo, but in the majority of cases I think it's better to have one repo per *.lang file.
Do a new gtksourceview-data tarball regularly (e.g. every month). When generating the tarball, the *.lang files would be downloaded from the upstream repos (gtksourceview-data would contain a list with URLs to download). By providing one central tarball, it's easier to package in Linux distributions.
When generating a new tarball of gtksourceview-data, if there is a 404 error for a certain *.lang file, copy that *.lang from the previous tarball.
For each *.lang file repo, there needs to be a public bug tracker, so if a maintainer no longer replies, we can see that there is no activity, and someone can fork the repo and we update the URL in the central list contained in gtksourceview-data. There needs to be no activity from the maintainer during a certain minimum duration, e.g. 3 months or 6 months.
To create a lot of small repos on GitHub or GitLab, a script can be written, using for example git-spindle.
Solution 2 - like the Linux kernel
See this article: Why Github can't host the Linux Kernel Community. The solution here would be to function similarly to the Linux kernel, with a MAINTAINERS file and sending patches by e-mails.
Solution 3 - GitLab?
GNOME is moving to GitLab. Maybe with GitLab we can find a better solution.