<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; ">The ability to extend it was introduced in Java 6. We could provide a <a href="http://docs.oracle.com/javase/6/docs/api/java/util/spi/LocaleNameProvider.html">http://docs.oracle.com/javase/6/docs/api/java/util/spi/LocaleNameProvider.html</a>.<div><br></div><div>We might be able to use it. But for the most part, we'd be duplicating/migrating the code in Languages, merely providing an alternate face to it that the application would be required to plug in.</div><div><br></div><div>But for now, we are on Java 5.</div><div><br></div><div>Regarding this whole topic. Bible Desktop only uses this in two places:</div><div>The tree display of modules where language is one of the classifications of Books.</div><div>The display of the module's conf.</div><div><br></div><div>The separate Jira issue is how to get the conf to be lazy in it's evaluation of the individual fields. Once that happens, the cost goes way down.</div><div><br></div><div>Having the full list is something I want for Bible Desktop. If it is not wanted for AndBible, STEP, AlKitab, ... maybe we can make it optional to have/use iso639full.properties and just call Locale.getDisplayLanguage().</div><div><br></div><div>In Him,</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>DM</div><div><br><div><div>On Feb 11, 2013, at 1:05 PM, Chris Burrell <<a href="mailto:chris@burrell.me.uk">chris@burrell.me.uk</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><p dir="ltr">Yes and off the top of my head I thought it was possible to tell java to extend the known set via some means without having to implement much ourselves</p>
<div class="gmail_quote">On 11 Feb 2013 17:23, "Martin Denham" <<a href="mailto:mjdenham@gmail.com">mjdenham@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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" target="_blank">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>_______________________________________________<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>
<br></blockquote></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>