[haiku-development] Re: Proposal for Haiku locale resouses reorganization.
- From: Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 30 Sep 2009 16:59:14 +0200
Hi Siarzhuk,
On 2009-09-30 at 15:00:37 [+0200], Siarzhuk Zharski <zharik@xxxxxx> wrote:
> On Wed, 30 Sep 2009 13:41:58 +0200, PulkoMandy wrote:
> > 2009/9/30 Siarzhuk Zharski <zharik@xxxxxx>:
> >> What is your meaning about this proposal?
> >
> > It's planned to get a simple website tool in place to track every
> > locale related work. This could be similar to the experimental one
> > used for the userguide translation, or more like trac, or like ubuntu
> > system... I'd like someone to take over this work, as I'm not
> > particularly a web-oriented developper. :)
>
> All that is nice, but my "pretension" is to the bloating the main system
> source tree. Most of developers will be satisfied by only one, default "en"
> translation, some will be happy with "en" and "ru", I'm going to start
> adding "by" ones soon. Can you imagine the simple Preference Application
> with only circa 5 source code files and catkeys for all possible languages?
> How many languages can we potentially have? But typical developer will need
> only one of them. Again, remember, that handling hundreds of small files
> can dramatically decrease the file-system performance.
>
> 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
Other related posts:
