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
scriptyrich(_at_)yahoo(_dot_)co(_dot_)uk