From: Ed Trager (ed.trager@gmail.com)
Date: Mon Jan 25 2010 - 11:07:30 CST
To toss into the fray an idea which undoubtedly has crossed the minds
of many readers of this list already, we must first recognize that the
idea of a "locale" is really a rather constraining and limiting
concept. Too constraining and limited for my taste.
Just as I do not like to wear a tight-fitting suit with a neck tie
that throttles my neck, so also I do not like rigid and inflexible
locale mechanisms within operating systems. It's much more
comfortable to have loose-fitting clothing, expandable waistlines, and
take the tie off altogether.
A locale, such as a locale in CLDR, is a bundle of data items that are
supposed to represent a "concensus" about the most accepted formats.
Heh heh. But in many communities, there may not be any true concensus
out there in the real "cloud" of the society.
Societies across the modern world daily become more pluralistic.
Achieving absolute concensus may not be compatible with increasing
pluralism in our societies.
As a personal example, here in America the short date format is
supposed to be "MM-DD-YYYY" -- and that really drives me up the
frickin' wall. I work in a medical research setting, and of course we
have collaborators who send us data from all over the world. Can you
imagine how many *useless* hours I have spent trying to tease out
whether a date is really "DD-MM-YYYY" instead of "MM-DD-YYYY"? So, in
all of the applications that I write, everyone is forced to enter
dates in the unambiguous ISO "YYYY-MM-DD" format which is neither the
American nor the British way. But that only solves the problem in my
little corner of the world that I can control. Often when data are
exported out of databases and into containers like OpenOffice or
Excel, guess what happens? The dates "revert" to "MM-DD-YYYY" format
because these programs are using the operating systems defaults.
Aarrggh!
I much prefer the idea of having an OS where I can set the individual
parameters of a locale -- and then those settings would actually be
respected by software across the board.
Of course that doesn't really solve CLDR's problem, does it? So,
maybe a solution for a data repository like CLDR would be to allow
storage of multiple choices per locale for all of those really pesky
and hotly-debated data items, like date formats or which day of the
week is supposed to be the first day of the week?
Maybe there needs to be a public voting mechanism where people's votes
determine the respective rankings of disputed data items? Maybe CLDR
should be like urbandictionary.com and have little "thumbs up" and
"thumbs down" icons that the public can vote on? :-)
- Ed
On Mon, Jan 25, 2010 at 9:38 AM, Yury Tarasievich
<yury.tarasievich@gmail.com> wrote:
> I don't see the purpose of such datasets as some vehicles of consensus. For
> a sake of argument, there is no metadata, no clear definition of 'community'
> and even of 'consensus'. Once some cr*p makes it into the dataset, one may
> argue till all went blue, the crap remains. I went through such motions year
> or two ago, achieving nil.
>
> Now, you tell me you don't have formal authority in Finland. But that's a
> basis for decision on Finnish dataset, precisely.
>
> So, to answer your initial assertion, I wouldn't put it quite like that but,
> well, yes. Better no entry at all, than an entry poorly prepared, even
> misleading.
>
> On 25.01.2010 12:37, Erkki I. Kolehmainen wrote:
>>
>> What you seem to be effectively saying is that the users don't need
>> localized systems. If they do, the user community is the only one to know
>> what is right for them. CLDR has made a mechanism public that allows
>> interested parties in any given user community to participate in the
>> definition process. They should use the opportunity and conduct an open
>> debate within and outside of the CLDR structure aiming at a consensus (like
>> we do in Finland where we have NO FORMAL AUTHORITY but a widely participated
>> and accepted process that leads to relatively solid data.)
>>
>> Admittedly, the CLDR Survey Tool doesn't have enough resources to
>> effectively handle any sizable volume, and something should be done about
>> it.
>
>
This archive was generated by hypermail 2.1.5 : Mon Jan 25 2010 - 11:10:09 CST