<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I checked a long time ago and it did not support many of the languages that SWORD has modules in.<div><br></div><div>We just added a module with a language of cbk (Central Kurdish), the result of <span style="font-family: Monaco; font-size: 11px; ">System.out.println(</span><span style="font-family: Monaco; font-size: 11px; color: rgb(147, 26, 104); ">new</span><span style="font-family: Monaco; font-size: 11px; "> Locale("ckb").getDisplayLanguage()); </span>is cbk.</div><div><br></div><div>From what I can tell, it supports most if not all 2 letter codes.</div><div><br></div><div>Some 3 letter codes for which there is a 2 letter code are not supported, E.g. azb should return the same as az.</div><div><br></div><div>The coverage for what we have in SWORD modules is spotty.</div><div><br><div><div>On Feb 11, 2013, at 12:22 PM, Martin Denham <<a href="mailto:mjdenham@gmail.com">mjdenham@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">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>
_______________________________________________<br>jsword-devel mailing list<br><a href="mailto:jsword-devel@crosswire.org">jsword-devel@crosswire.org</a><br>http://www.crosswire.org/mailman/listinfo/jsword-devel<br></blockquote></div><br></div></body></html>