Can someone explain our locale offerings to me? Our locales seem to be
in a hodgepodge of different states and I would like to clean them up a
bit. Various issues are listed below:
1) Why do we even have an en_GB locale? It is identical to the default
(en) locale.
2) A number of locales have the format xx_YY-zzzz where xx is a language
code, YY is a country code, and zzzz is an encoding. Others have simply
xx-zzzz (language-encoding, where encoding is always utf8 for this set).
Is there a POSIX locale format that requires a country code to be
present if an encoding is specified?
The Arabic locale, for example, is specified as Egyptian, but I strongly
suspect there is nothing particularly Egyptian about the book name
translations. I think it would greatly simplify matters if those locales
which specify a country code were changed to omit that code.
The only locales I would exempt from this change are zh_TW (where this
conveys the use of Traditional Chinese) and pt_BR (which actually
contrasts with the pt locale).
3) There are xx_abbr or xx_abbrev locales for German, French, Estonian,
and Korean and an abbr locale for English. Does anyone actually use any
of these as their locale? Or are they used in some other way by any
front end?
This might have to wait a while, since I foresee it requiring an API
change, but I would like to fold these into their language's primary
locale files. (I.e., where we currently have sections called [Meta],
[Text], and [Book Abbrevs], we would add an [Abbr] section.) Then we can
add methods to retrieve abbreviations instead of full book names. This
allows us to reduce the redundant [Book Abbrevs] sections and avoids the
current situation where locale selection drop-downs include a bunch of
languages plus a bunch of localized abbreviations.
--Chris
_______________________________________________
sword-devel mailing list: [email protected]
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
