> 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
