Re: WIP citrus patch

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

Matthew Dillon wrote:

> :> Hi all,
> :> for those of you wondering about the recently added files,
> :> I'm working on integrating the Citrus framework from NetBSD.
> :> The patch at http://leaf.dragonflybsd.org/~joerg/citrus4.diff
> :> is the current stage, but it is *not* final. This needs an
> :> libc major bump, which will be used to clean certain other
> :> parts of libc up too. Consider this mail as FYI if you don't
> :> completely know what you are doing :)
> :> 
> :> After applying the patch, if you want to test it, remove the
> :> empty files from src/include, otherwise Bad Things Happen(tm).
> :> 
> :> Joerg
> :
> :Noted, massive job, and and *Very  welcome* work for the
> :'internationalists' among us. Thank you!
> :
> :Homepage is here for anyone not familiar:
> :
> :http://citrus.bsdclub.org/index.html
> :
> :Bill
>
>     Nice URL reference.  It looks like exactly what we want.

Joerg Sonnenberger's initiative - I was just the 'historian'  ;-)

>     A couple of us have been talking about how to do a major libc bump
>     gracefully.  At the moment I think that since we will be doing major
>     work on several areas of libc that will require the version bump, 
>     we should probably rename the current libc source hierarchy libc4 and
>     dup the CVS tree to create a libc5, and then be able to select one or
>     the other for the buildworld (with it defaulting to libc4).  Not both,
>     just one or the other :-) (because the /usr/include files need major
>     work too).   This way a subset of developers who want to track the 
>     new work and who know how to deal with libc blowing up the whole 
>     system can, and everyone else can stick with libc4.
>
>     Joerg is investigating the Makefile framework required to make this
>     happen.
>
> 					-Matt

Sounds practical.....

An International Telecoms career, content-hopping life-style,
multi-lingual wife, and the observation that no ethnic group has
(yet) been granted a patent on brains or coding skills, make i18n very
dear to my heart.

So far, 'userland' tools in, for example, Zope/Plone (see our precisa.ch)
 have sufficed.  But the F/OSS community of coders need something closer
to the bone if we are to effectively share work on 'system' infrastructure.
- Especially to ease building those userland apps more efficiently in 
future.

At the same time, I note that 'citrus' is itself an under-resourced project,
(as are most such) so keeping the i18n-relevant toolset 'modular'
seems very wise.

- As with 'X' - It may someday have to be swapped for a different one
or made optional.  'libi18n' breakout from libc{x} even...

I don't code C, but docs and research I *can* do .. just ID the need.

Bill