(from the CLDR-users archives; source: CLDR-users index for Mar. 2007)
From: "Don Osborn"
To: <cldr-users@unicode.org>
Cc: "'CLDR list'" <cldr@unicode.org>
Subject: RE: Concerns about relative dates
Date: Fri, 30 Mar 2007 08:44:03 -0400
Thanks Addison, this helps me to understand some of the issues. I somehow thought that CLDR was tied more closely to localization of software and software's ability to interpret basic data appropriately for a locale. Problem for me is that I don't have programming experience to see how these are used in practice.
Nevertheless, when the number of terms begins to make CLDR look like "common localization dictionary repository" (nice way of putting it), then it begins to look to a non-programmer like there might be two different sets of needs combined under one project. Has any thought been given to separating out basic locale data on one hand from more extensive localizers' dictionaries on the other? I'd be tempted to suggest a "Wiktionary" approach to the latter that permits localizers to constantly add and improve on definitions without debates over the appropriateness of categories, while at the same time being a "fundamentalist" on the former (that is, the locale data maintained in CLDR, with limited periods for input etc.).
One reason that I am thinking about this is that I'm looking at the need to put together locale data for basic localization in many languages, and the fact that adding a lot of specialized references to be translated adds to the burden without facilitating the main immediate goals for these languages (localized software, accommodation of localized web content). Even something like names for all the countries and many world languages poses difficulties (there was a remark not long ago on another list about how to translate Bosnia Herzegovina into Swahili). You end up either forcing translations that likely will have to be revised (again in the case of Swahili there was an issue about different renditions of Côte d'Ivoire), or leaving them blank (putting off completing a locale in CLDR until the next round of revisions, or the one after that).
Having looked at the locale data fields for OpenOffice, it seems these are less numerous, since the purpose is very specifically for that software. So again I wonder in the case of CLDR about focusing on basic locale data while providing another mechanism (perhaps a Wikitionary approach) for what one might term "extended" locale data (shoe sizes, nautical terms, day-before-the-day-before-yesterday, etc.).
Don
< RE: Concerns about relative dates | CLDR-users | RE(2): Concerns about relative dates >