Perl i18n/l10n limitations?

Hello everyone

I'm going to follow up my previous post:

From my admittedly limited knowledge of i18n, there seem to be fundamental 
problems with i18n/l10n in perl:

Built in support seems limited to charsets, collation, and basic number 
formatting (printf etc). To query localization information, you have to 
rely on POSIX functionality which may or may not be present, and the 
information returned varies from platform to platform (what on earth do you 
do on Win32?)

The future of perl appears to be utf8, but perlunicode states: "Use of 
locales with Unicode is discouraged" - this removes perl's built in support 
at a stroke.

The only attempt at a formal framework I've found was picu 
http://sourceforge.net/projects/picu/ , a perl wrapper around IBM's ICU 
internationalization framework, but it's clearly dead. That's a pity, since 
it attempted to provide support as comprehensive as, say, Java (which 
apparently uses ICU anyway).

At the very least perl needs a Locale class - instances would provide the 
attributes needed by i18n routines. Serialized Locales could be provided as 
part of official perl releases, and only in cases where a locale was not 
supplied would the underlying OS be queried. For modules requiring i18n - 
DateTime, Number::Format, Math::Currency, ...name it!... i18n methods would 
take a locale argument and base l10n on the information provided by the 
passed Locale. This could provide a limited starting point to OS 
independent localization with smaller granularity than the existing Locale 
pragma offers - eg. per thread rather than per process.

I realise what I'm proposing is exactly how locales are provided in many 
languages with "formal" locale support - nothing original here at all - but 
that doesn't get away from the fact that perl needs it IMHO.

Does what I've said make sense? Has anyone done anything like this already? 
Are there any folks in the perl community that I could talk to about this?

Thanks,
--
Rich
[email protected]