Subject: heads up -- switching to IETF language codes
From: Paul Rohr (paul@abisource.com)
Date: Thu Feb 17 2000 - 01:17:41 CST
On Fri, 21 Jan 2000, I wrote:
> [1] I forget *why* we don't just use strict IETF-style spelling of locale
> names. Does anyone remember?
Jeff has pleaded amnesia, and I haven't heard any other good reasons for
staying different, so I thought I'd check once more. Does anyone know of a
really good reason why we should *not* convert to IETF-style spellings for
our localizations?
If not, we'll probably implement the change in the next few days, so if
you've got any patches pending which might be affected by this change, now's
the time to speak up.
overview
--------
There seem to be a total of three possible naming conventions in play here:
examples who uses it
-------- -----------
en_US, pt_BR, etc. LC_CTYPE
en-US, pt-BR, etc. IETF, IANA, XML, etc.
EnUS, PtBR, etc. just AbiWord (content and filenames)
On most of our platforms, we've already added logic at various spots to
convert back and forth from the existing AbiWord convention to something
more standard. This seems silly.
Worse, when we start getting translations for languages which have a
3-letter code, but not a 2-letter code, we won't be able to do fallback
parsing on either side of a dash. Instead we'll have to be looking for case
changes, which is doable, but ugly. (Yeah, it's a nit, but do *you* want to
argue with a Masai speaker about it?)
So...
proposed solution
-----------------
Do any of our supported platforms care if we use dashes in filenames? If
not, then perhaps we'd be best off conforming by making a one-time treewide
change to the IETF/XML convention. For example,
from to
---- --
EnUS en-US
FiFI fi-FI
NoNO no-BOK
NoNYN no-NYN
Before doing so, I do want to make *absolutely* sure that this won't cause
significant problems anywhere, though. This change would touch quite a few
files across the tree, and I'd hate to have to undo it all later.
impact
------
Primarily, this means renaming all of the following files:
abi/src/wp/ap/xp/ap_Menu_LabelSet_????.h
abi/src/wp/ap/xp/ap_TB_LabelSet_????.h
abi/user/wp/strings/????.strings
abi/user/wp/help/????/*
abi/user/wp/sample/????/*
Likewise, the contents of many of these files may need to be tweaked to
export the renamed locales (at the top of the file). In addition, the EnUS
string has been hardcoded into the following files:
abi/src/af/xap/win/xap_Win32App.cpp
abi/src/af/xap/xp/xap_Strings.cpp
abi/src/wp/ap/<platform>/ap_<platform>App.cpp
abi/src/wp/ap/<platform>/ap_<platform>Prefs.cpp
abi/src/wp/ap/xp/ap_LB_*.cpp
abi/src/wp/ap/xp/ap_Menu_LabelSet.cpp
abi/src/wp/ap/xp/ap_Prefs_SchemeIds.cpp
abi/src/wp/ap/xp/ap_Toolbar_LabelSet.cpp
Finally, I should also note that this change *will* break the existing
Preferences settings for non-English speakers. However, that's a one-time
event, and if I had to choose when to address it:
now -- when our user base is in the hundreds of thousands, or
later -- when it's in the millions
Well, I know which I'd prefer. :-)
Paul
motto -- the world only needs *one* word processor, AbiWord
This archive was generated by hypermail 2b25 : Thu Feb 17 2000 - 01:12:15 CST