Rick Measham wrote:
>> 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.
>
> I'd really like to not depend on Locale.pm other than as a loader for
> normal, included Locale methods.
>
> Can we just have an API that any module could potentially use?
>
> Suggested subset of requirements for a Locale module that could be called
> on by DateTime:
>
> $locale->short_date_format();
> $locale->medium_date_format();
> $locale->long_date_format();
>
> $locale->short_time_format();
> $locale->medium_time_format();
> $locale->long_time_format();
>
> $locale->short_datetime_format();
> $locale->medium_datetime_format();
> $locale->long_datetime_format();
>
> $locale->english_name(); # 'English - Australian'
> $locale->language_iso_code(); # en
> $locale->country_iso_code(); # au
> $locale->encoding(); #UTF-8, Latin1 ... ?
>
> And others .. the point is that users can use any module they want for
> their locale, so long as it has the appropriate methods.
>
>
> $dt = DateTime->new(%date, locale => 'en_au');
>
> Arg locale is a scalar, therefore we pass it to Locale.pm, which loads the
> appropriate module.
>
>
> $locale = new My::Locale;
> $dt = DateTime->new(%date, locale => $locale);
>
> Arg locale is an object, therefore we call our methods on that object.
>
> If there's a reason why we can't do this (other than 'I don't like it'),
> please let me know. From what I can make out from the Locale alphas,
> there's no reason we can't bend things around to work like this.
>
> Richard: would this make for a huge amount of extra work for you, or would
> most of the work be altering DateTime.pm?
>
> Cheers!
> Rick
Ok this is really a reply to everyone who's commented so far.
DT::Locale was only designed as a replacement for DT::Language to increase
the relatively limited coverage provided by DT::L. It was also designed as
plug in replacement - certainly last time I tried it (a while ago,
admittedly), you can simply put a locale object into $dt->{language} and
away it goes (with reduced functionality of course).
But there's nothing forcing you to use DT::Locale as long as you implement
the full API functionality required by DateTime, and I guess that API is
for others to decide on. The only thing you might lose is the ability to
query DT::Locale for a list of installed locales.
Just in case anyone isn't aware, the full Locale object API is defined in
DateTime::Locale::Base.
The LocalInstall (maybe CustomInstall?) idea is a way of adding custom
locales in a relatively painfree manner. If it's simply a case of needing
an arbitrary namespace, then I guess register_locale() could take the
absolute filepath as well and require "" it.
But if folks want an all singing, dancing framework, then I'll quietly bow
out and let someone else take that on :)
Cheers,
Rich
--
Richard Evans
[EMAIL PROTECTED]
