I had been wondering if we actually needed the list of language names at all. The Locale class provides many functions such as getDisplayName, getDisplayLanguage(Locale inLocale), getISOLanguages, getISOCountries, etc.<div>
<br></div><div>Martin<div><br><div class="gmail_quote">On 11 February 2013 16:55, DM Smith <span dir="ltr"><<a href="mailto:dmsmith@crosswire.org" target="_blank">dmsmith@crosswire.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I've been looking at the issues regarding the Language and Languages classes; bcp-47 (the standard that defines the designation of Locale); java7's support for it in Locale; and what SWORD has defined.<br>
<br>
First, the basic purpose of the JSword classes is to provide a friendly name for the language code. It is not meant as Locale support.<br>
<br>
There are 7000+ languages, so JSword splits these into two.<br>
First Part:<br>
Those languages that are in use by SWORD modules on the CrossWire server and those found on the CrossWire wiki under <a href="http://www.crosswire.org/wiki/Localized_Language_Names" target="_blank">http://www.crosswire.org/wiki/Localized_Language_Names</a>.<br>
<br>
These are in the iso639.properties property files. When we started out, this name was appropriate, but it has morphed into names in the above list. So really it is a subset of bcp-47.<br>
<br>
These files can be localized. The default file has localized names from the wiki. Failing that from <a href="http://www.sil.org/iso639-3" target="_blank">www.sil.org/iso639-3</a>.<br>
<br>
The iso639_en.properties file is similar to the default file, but has the localized name in parens following the English name.<br>
<br>
So the default is not English.<br>
<br>
Second Part:<br>
As a fall back to the First Part, if there is a new SWORD module for a language that is not covered by the first part, we can do one of two things:<br>
a) Just show the code as the language name.<br>
b) Show the name as defined by SIL's iso639-3 files.<br>
<br>
The property file iso639full.properties is a map of 2 and 3 letter language codes to the name of the language from SIL's files. This is a huge, slow property file.<br>
<br>
Since this is a fall back, this file has no need to be internationalized.<br>
<br>
BCP-47 and SWORD:<br>
This standard far exceeds what SWORD allows in a Lang field. SWORD defines the field as having a required part and two optional parts: LL-SSSS-CC<br>
Where LL is required and a 2 or 3 letter language code.<br>
Where -SSSS is the optional, 4 character script.<br>
Where -CC is the optional, 2 character region code.<br>
The following are valid combinations:<br>
LL<br>
LL-SSSS<br>
LL-CC<br>
LL-SSSS-CC<br>
<br>
The parts are case insensitive.<br>
<br>
In Chris Little's recent email to the sword-devel list, the lookup algorithm should be:<br>
Given LL, look for LL.<br>
Given LL-SSSS, look for LL-SSSS and failing that look for LL.<br>
Given LL-CC, look for LL-CC and failing that look for LL.<br>
Given LL-SSSS-CC, look for LL-SSSS-CC, LL-SSSS, LL-CC and lastly LL.<br>
<br>
In the last one SSSS is prioritized over CC because the script has more impact on the representation of the name than the region does.<br>
<br>
JSword does not properly support this. I thought it did.<br>
<br>
Java Locale:<br>
Java Locale has a fatal flaw in that if given "he" (Hebrew), "yi" (Yiddish) or "id" (Indonesian) or no-NO-NY (Norwegian spoken in the Norsk region) it will change these to "iw", "ji", "in" and "nn-NO" and not remember what it was given. There are a few other re-write exceptions too. The Hebrew, Indonesian and Norsk affect our users.<br>
<br>
Java 7:<br>
Introduces support for script. And it introduces a parser via Locale.forLanguageTag(); But given the flaw above we'd have to write a work around for what it does. Also, it will be quite a while before we get to Java 7.<br>
<br>
JSword's Languages and Language classes:<br>
The Languages classes is meant to support the lookup of a SWORD Lang field and provide a friendly name for it.<br>
The Language class is meant to be a holder of the result of that lookup.<br>
<br>
Currently this needs some love to get to do what it needs to do. I'm trying to provide it.<br>
<br>
For example Languages does not expect - between parts but _ (I thought it was the other way around). It ignores the _ and everything that follows. This needs to be replaced with a proper parsing of LL, SSSS and CC.<br>
The lookup currently is for only the LL. It needs to change to do all the lookup aspects.<br>
<br>
Language needs to change to include SSSS. Currently, it does not store the value used to do the lookup, but rather what was effective in doing the lookup.<br>
<br>
There are a number of issues open on the problem and I hope to resolve them all, but may need some help in reproducing them.<br>
<br>
In His Service,<br>
DM<br>
<br>
<br>
<br>
_______________________________________________<br>
jsword-devel mailing list<br>
<a href="mailto:jsword-devel@crosswire.org">jsword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/jsword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/jsword-devel</a><br>
</blockquote></div><br></div></div>