On 2012-06-06 09:35, Boruch Baum wrote:
CRITICISM: As Andy Lipscomb, Brian Inglis and Peter Machata all recently posted, localizations for all timezone names and abbreviations can (and should) be expected to be in the local language and character set.
Who is/are responsible for maintaining each locality's localization lists, in order, for example, to guarantee uniqueness?
The GLIBC library of GNU/Linux currently has a function nl_langinfo, which gives programmers an easy way to localize pretty much all time and date related data elements... but not timezone names or abbreviations. The GNU/Linux coreutil commandline 'date +%Z' command will return a timezone abbreviation, but seemingly never localized. I see no option in the GNU/Linux coreutil commandline 'date' command to return a timezone name.
So how do locales represent timezone strings in their own localization?
I recently started testing my libhdate collection under a variety of locales, so I had a small script all ready for this test:
===================================================================== #!/bin/bash # locale_test.sh # execute an arbitrary command from a list of locales # note: the locales must first be defined using localedef(1). This usually requires administrator privileges
locales=( \ he_IL Hebrew Israel \ de_DE German Germany \ pt_BR Portuguese Brazil \ ru_RU Russian Russia \ ar_MA Arabic Morocco \ es_AR Spanish Argentina \ es_MX Spanish Mexico \ fr_FR French France \ fr_CA French Canada \ hi_IN Hindi India \ fa_IR Farsi Iran \ ja_JP Japanese Japan \ ko_KR Korean Korea \ hy_AM Armenian Armenia \ ka_GE Georgian Georgia \ am_ET Amharic Ethiopia \ zz )
i=0 while [[ "${locales[$i]}" != "zz" ]]; do echo -e "\e[48;5;234mcommand: $*, locale: ${locales[$i]} ${locales[$i+1]} ${locales[$i+2]}\e[01;00m" env LC_ALL=${locales[$i]}.UTF-8 $* i=$i+3 done
===================================================================== $ ./locale_test.sh TZ='Asia/Tehran' date +"%A_%B_%Z" command: TZ=Asia/Tehran date +%A_%B_%Z, locale: he_IL Hebrew Israel רביעי_יוני_IRDT command: TZ=Asia/Tehran date +%A_%B_%Z, locale: de_DE German Germany Mittwoch_Juni_IRDT command: TZ=Asia/Tehran date +%A_%B_%Z, locale: pt_BR Portugese Brazil quarta_junho_IRDT command: TZ=Asia/Tehran date +%A_%B_%Z, locale: ru_RU Russian Russia Среда_Июнь_IRDT command: TZ=Asia/Tehran date +%A_%B_%Z, locale: ar_MA Arabic Morocco الأربعاء_يونيو_IRDT command: TZ=Asia/Tehran date +%A_%B_%Z, locale: es_AR Spanish Argentina miércoles_junio_IRDT command: TZ=Asia/Tehran date +%A_%B_%Z, locale: es_MX Spanish Mexico miércoles_junio_IRDT command: TZ=Asia/Tehran date +%A_%B_%Z, locale: fr_FR French France mercredi_juin_IRDT command: TZ=Asia/Tehran date +%A_%B_%Z, locale: fr_CA French Canada mercredi_juin_IRDT command: TZ=Asia/Tehran date +%A_%B_%Z, locale: hi_IN Hindi India बुधवार _जून_IRDT command: TZ=Asia/Tehran date +%A_%B_%Z, locale: fa_IR Farsi Iran چهارشنبه_ژوئن_IRDT command: TZ=Asia/Tehran date +%A_%B_%Z, locale: ja_JP Japanese Japan 水曜日_6月_IRDT command: TZ=Asia/Tehran date +%A_%B_%Z, locale: ko_KR Korean Korea 수요일_6월_IRDT command: TZ=Asia/Tehran date +%A_%B_%Z, locale: hy_AM Armenian Armenia Չորեքշաբթի_Հունիսի_IRDT command: TZ=Asia/Tehran date +%A_%B_%Z, locale: ka_GE Georgian Georgia ოთხშაბათი_ივნისი_IRDT command: TZ=Asia/Tehran date +%A_%B_%Z, locale: am_ET Amharic Ethiopia ረቡዕ_ጁን_IRDT =====================================================================
- From my perspective, it would be best if nl_langinfo would be extended to include timezone names and abbreviations. That would make it trivial to write code that would portable across all locales, and would be able to auto-magically accept timezone names and abbreviations in the user's selected locale.
Of course, nl_langinfo just picks up data from locale definition files, so this still would mean each locale having a complete set of entries for each timezone name and abbreviation (just as each dos now month names, days of week).
CLDR would need to collect timezone names and abbreviations for each combo of Olson/IANA timezone (which specifies an associated territory/ country code in the zone.tab file), standard/daylight state, and languages used in that territory. So for any timezone and territory, localization is likely to be possible only for those languages used (or the subset provided in the CLDR, which may be only the officially supported languages) in that territory for that timezone and state. For Canada, English and French names and abbreviations are provided, but do how those are rendered into say Chinese, Arabic, and Hebrew depend on whether the populations using those languages are in North American English, French, or their native locales? So limited localization may be supported by CLDR, but it is likely to be a large effort and a long time before internationalization of timezone names and abbreviations could be supported, as the locales required could be a large subset of the product of all languages and territories.