That is why I think that non-default localization data resources should
be
moved out of main trunk. Such data are not sources but kind of optional
stuff. And we have to do this separation before the trunk bloats.
I certainly agree and find the idea pretty neat. We need to make up our
mind
about how to *package* the locale stuff (catalogs) anyway. IMHO it
doesn't
make sense to always build all existing catalogs and copy those onto the
image. I've always found it pretty strange that there are so many
translation
files installed on Linux although I'm only ever using 1 or 2.
If we move the catalogs into a different subversion module, it would be
nice
to keep it integrated with the build-system in haiku-trunk, such that the
build-system would notice which other languages are available (and
allows to
select from these by setting a variable in UserBuildConfig). Of course,
somebody would have to work on the required jam rules for that.
And the last point - separating localization resources out of the system
sources will simplify the administrative actions for maintaining the
localization resources branch - then you can let the write access to
corresponding parts of the SVN repository to people, that maintain
corresponding language. Currently it looks overcomplicated and I see,
that
you have to work as "commit proxy" and resolve all conflict between
different "flavors" of translations.
Indeed - if we separate the translation catalogs from the code, it would
be
rather simple to allow more people write access to those (once we've
switched
to our new svn server). With a couple of more jam rules, it should even
be
possible to get jam to not only build the catalogs, but collect info
about
the state of the different languages/app translations.
I think if we can get that to work, the need for a web application
tracking
the translations would be much less pressing.
cheers,
Oliver
