Thanks again for the feedback. I appreciate the ideas very much and
look forward to working with everyone on this a bit.
Here are the issues that need addressed as I see them, I'd love to
hear your thoughts as well:
As far as locale data goes, it'd seem to make the most sense to put
all the common CLDR in DateTime::Locale, its central, it standard.
There still needs to be a "recommended" Localization procedure for
DateTime::Format based modules because
a) its being done inconsistently
b) not all things will be able to use CLDR only.
An example of those are DateTime::Format::Human which uses an internal
hash of the data with ISO code's as keys (except the "funny" ones are
not prefixed w/ i-) , DateTime::Format::Baby which also uses a hash
but uses the long-english version of the language as the key (IE
'English')
What I think would be ideal is:
- DateTime::Locale has all date time related info scraped from CLDR
- if a module needs localization it uses everything you can from
there
- if the available data is not fully sufficient for the goal of
the module then a ::Locale subclass that has a method to get the data
and/or logic from Locale::en, Locale::fr, etc
What I am attempting is a single format only. One that requires no
logic from the programmer to determine the language to use or the
details of the format.
The way my module does this is it determines the locale based on the
DT based objects involved and/or arguments. Tries to load
it's ::Locale::XX and use the data/logic from there for that and
future requests (from specific to generic E.g en_us, then en).
In this case CLDR would be very reusable there with the names
involved, probably 'and' and the oxford comma. There is still no
facility for saying 'no time difference' and the logic is still forced
to be english centric in the single/plural senses (what about dual
tenses?) and in the structure of the phrase (hence the locale method
to do the logic anyway they need to)
That is why CLDR is defintley a good idea but won't be a 'Universal
Catchall' since logic is involved and hence the ::Locale subclass
idea. The logic for determining the locale that should be used can
easily be (and was originally but I decided to wait and see how it'd
fit into the DateTime project's Locale setup first)
As far as DateTime::Format::Duration goes it would seem to me to be
exactly what it is: a strftime type method for durations. It processes
any given format. Period,its perfect, don't mess with that.
Besides it'd be difficult and not really fit anyway to make it
generate those formats for you because there are all sorts you might
want:
1 day, 3 hours, and 37 seconds (what mine does)
4 score and 7 years
hour and a half
little over a year
few months
month of sundays
pretty soon
etc
plus locale wise you have to consider:
singular, dual, plural, maybe even zeroth
past present and future tenses
perfect imperfect aspects
etc etc
In summary, it would be awesome to fetch from DateTime::Locale what
you can but also have a consistent way to encapsulate locale info/
logic very specific to the format a given module is going for.
All of that said, I'm more than happy to work with Dave or Rick or
anyone on any modules to get it so it all fits together nicely, let me
know!
Perhaps DateTime::Format::Duration::TYPE should be what work with a
specific format type and any locale data/logic not in DateTime::Locale
can be in DateTime::Format::Duration::TYPE::Locale[::XX] ?
In the meantime, we work at getting DateTIme::Locale to hold all the
datetime related data from CLDR ?
What do you think?
On Jul 28, 2008, at 8:12 PM, Rick Measham wrote:
Dave Rolsky wrote:
This all seems like it could go into DT::F::Duration though, just
with different strftime-type specifiers (or CLDR, or whatever).
Absolutely it could and should. %c and %x and %X would be the
obvious first candidates along with the alternate %{...} format for
other CLDR formats.
Dan, please consider working at extending DateTime::Locale to
include the duration formats and then working at helping me to
extend DateTime::Format::Duration to make use of that data.
Alternately, once CLDR duration locales are imported into
DateTime::Locale, write a module named something like
DateTime::Format::Duration::Locale that makes use of the data.
The normalisation functions in DateTime::Format::Duration give it
its real power so I would suggest you wrap the _as_deltas methods in
whatever you decide to do.
Cheers!
Rick Measham
--
Message protected for iSite by MailGuard: e-mail anti-virus, anti-
spam and content filtering.
http://www.mailguard.com.au
