Hi everyone
It's clear that some folks are going to need custom locales whatever the
coverage of the core DT::Locale modules. It's also pretty clear that
DT::Locale isn't very friendly when you want to such locales:
Currently you have to add an entry into the DateTime::Locale::_locale method
array, which gets clobbered every time a new release of DT::Locale happens.
Not nice.
What I propose is this:
1) Add a register_locale method to DateTime::Locale:
DateTime::Locale->register_locale(de => 'deu', 'ger', 'German', 'Deutsch');
Arguments are: locale id, ISO 639-2(T) equivalent, ISO 639-2(B) equivalent,
English locale name, Native utf8 locale name. These will all be required
for the next DT::Locale release anyway.
Once registered, the locale can be load() ed and treated like any of the
core Locale modules.
2) Somewhere at the top of DateTime::Locale, add:
eval
{
require DateTime::Locale::LocalInstall;
"DateTime::Locale::LocalInstall"->import;
};
DateTime::Locale::LocalInstall is guaranteed never to be supplied with
DateTime::Locale - it's solely designed for users to register their custom
locales, and will look something like:
package DateTime::Locale::LocalInstall;
use strict;
use DateTime::Locale;
sub import
{
# Register as many custom locales as you like here
DateTime::Locale->register_locale(en_GB_RIDAS1 => 'eng_GB_RIDAS1',
'eng_GB_RIDAS1',
'eng_GB_RIDAS1',
'Ridas custom locale1',
'Ridas custom locale1');
}
1;
Obviously I'd provide the code template in the DT::Locale docs somewhere.
So this is how it would work - you write custom locales, shove them in one
of the @INC paths (preferably different to the DT::Locale install path) and
add the LocalInstall module which is used to register your locales.
Reasons why I like it:
1) New DT::Locale releases will not effect installed custom locales - no
hacking DateTime::Locale.pm to add new entries.
2) Easy to implement - just done it ;->
Reasons why its evil:
That's for others to comment on!
Does this make sense? Any suggestions?
--
Richard Evans
[EMAIL PROTECTED]
