WIP citrus patch

[Bill Hacker]

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