[tex-live] New babel locale files

[Mojca Miklavec]

On 9 June 2017 at 00:09, Karl Berry wrote:
>
> And one other question, just for information: who is maintaining all of
> these new files? You? The individual babel-* maintainers, who feed
> changes back to you? (The *.ini files have no bug-reporting information
> at all, nor does the README-locale explain.)
>
> In any case, it seems a step backward to return to having all this
> information in one centralized package. You say in the README they're
> essentially "finished" (except for the ones that aren't :), but it seems
> highly improbable to me that they will need no maintenance. This is just
> the situation we went through with babel the first time, when it was
> unfortunately stagnant for many years due to centralized control.

My personal point of view is that it makes much more sense to keep
things centralized (but open) in this case.

A counter example for the old babel situation is what you end up when
various people (did not) maintain hyphenation patterns. Each file with
its own language and file naming convention, each file with its own
set of macros, each one incompatible with each new engine on the
horizon.

It makes a lot more sense to me to keep one central repository
somewhere in the open (some svn or git repository that's accessible by
anyone), keep a somewhat open policy, so that individual language
files can have some kind of "individual maintainers" that keep adding
new translations, potentially correcting the old ones, providing input
and feedback when new functionality gets added, ...

When new functionality gets added or when the format of localisation
files changes, it makes sense to keep files at one central place and
modify them all at once. This also makes sense in the light of
potentially merging Babel and Polyglossia one day (even if not
entirely merging, they could get the translations from the same pool
of strings for example).

(Non)maintenance of any package is something that should be solved on
a different level. If the maintainer disappears, one needs to have a
mechanism for someone else to pick up where the previous maintainer
left off. Even if individual language files for Babel were
decentralized and the core package was "locked and unmaintained" at
the time when XeTeX came up, this wouldn't really help in any way.

The important thing is:
- to have a source repository available in public
- to have a tracker available somewhere, so that even if the
maintainer doesn't respond quickly, other users can still have access
to patches submitted by their fellows
Nowadays that's much easier than years ago when all the personal
emails would end up in the void.

Mojca