[sword-devel] language/locale codes

Chris Little chrislit at crosswire.org
Tue Nov 10 23:46:40 MST 2009

Some of you have noticed my commits of language/locale data, and I 
wanted to outline my near-term plans and long-term hopes for that work.

First, it should be borne in mind that the whole situation is vastly 
more complex than most of us are probably aware. Long ago, we adopted 
IETF's locale naming convention for identifying languages, which was 
defined in RFC 1766. This was obsoleted in favor of RFC 3066, which was 
in turn obsoleted in favor of BCP 47, which currently identifies RFCs 
4646 and 4647.

RFC 4646 defines the syntax and sources of locale subtags. For the 
language subtag, tags are defined by (in order of preference): IANA, ISO 
639-1, ISO 639-2/T, ISO 639-3, and ISO 639-5. Script subtags are defined 
by ISO 15924, and region (e.g. country) subtags are defined by ISO 3166-1.

I committed a bit of Perl that will grab the latest versions of all of 
this data from each registration authority (IANA, the Library of 
Congress, SIL, Unicode, and ISO), and I've got another pair of files in 
which I list the native names for many of the languages (copied from 
Xiphos' database) and list those code actually used by Sword modules or 
locales. I'm in the process of writing another script that will parse 
through all of the files and output a big, easy to parse, master 
database of locale data.

 From that, we can generate up-to-date data for each front end in the 
format that it needs and according to the desires of each team. So if 
the BibleTime and Bible Desktop teams only want to ship locale data for 
modules that are already shipped, we can filter everything else out. If 
a team were to prefer the English names to native names, we could 
produce that.

Longer term, it would be nice to push this functionality back into the 
library so that front ends can all share the benefits of updated data 
without having to deal with updates or the particulars and eventual 
changes in BCP 47. But that will obviously require API changes, which 
are not permitted, last I heard.


More information about the sword-devel mailing list