[sword-devel] Locale - proposal

[Troy A. Griffitts]

Hi guys,

Let me clear up 2 things, and suggest a third.

1) SWORD does have fallback locale logic:

http://crosswire.org/svn/sword/trunk/src/mgr/localemgr.cpp
(search for setDefaultLocaleName)

The problem is here:

if (!getLocale(tmplang)) {

// then continue to search for a fallback

}

getLocale never returns NULL. At some point, we changed it to return the 
default ("en_US") if a locale was requested which doesn't exist (which 
obviously makes the "if (!getLocale(...))" check never true).

This is a bug and should be the check should be changed to:

if (locales->find(tmplang) == locales->end()) {

I have just checked in a bug fix (and so the link above with show fixed 
code, sorry, but you can guess what it used to read).


2) If you'd like to display locale names to the user, please consider 
using the meta locale "locale" (file:locale.conf), which has an 
exhaustive list of all known locales along with their English 
counterparts. This can be used like this:

LocaleMgr *lm = LocaleMgr::getSystemLocaleMgr();
std::cout << lm->translate("de", "locales") << "\n"; // prints "Deutsch"
std::cout << lm->translate("de.en", "locales") << "\n"; // prints "German"

Peter, you may wish to grab the SystemLocaleManager as I've done above 
rather than using your previously posted:

LocaleMgr *localeMgr = new LocaleMgr();

This will save you scanning all the folders and reloading all the 
discovered locales.

But we seem to have an inconsistency here. In our locales.d/ files we 
use, e.g.,

Name=zh_Hant

In the locales.conf we use:

zh-Hant=繁体中文

(note the _ vs. -)

We also have many inconsistencies between our locale names and what is 
in the exhaustive locales.conf file.


3) Yeah, I agree with both of you that: a) if we have a specific locale 
but no general parent, the specific should be copied to the parent until 
such time as we get a better parent; b) we should not duplicate the 
other way round general to specific, as the fallback mechanism will 
cover this.

And finally, we need to clean this stuff up and make it consistent.

Chris, what would you suggest to use between underscore and dash, e.g., 
"zh_Hant" or "zh-Hant"?


Remember, we have MANY MORE language modules than we have locales for 
the engine. Wycliffe alone has made sure of this. The locales.conf file 
is intended to help frontend developers display language names to end 
users when they come across a module language code.

Having said this, using it for looking up a display name for a language 
from our locales should be an acceptable use as well, as suggested here.

We just need to be sure we are consistent between:

module.conf: Lang=zh_Hant
locale.conf Name=zh_Hant
locales.conf: zh_Hant=


Troy



On 01/03/2014 11:10 AM, DM Smith wrote:
>
 > On Jan 3, 2014, at 11:37 AM, Peter von Kaehne <refdoc at gmx.net>
 > wrote:
 >
 >>> On Fri, 2014-01-03 at 10:54 -0500, DM Smith wrote: BTW, I like
 >>> how Java searches for localized resource files. The actual
 >>> implementation is rather complex (because it searches multiple
 >>> locations), but to simplify: Given a language code, a country
 >>> code and a script code (script is new to Java 7), it looks for
 >>> the most specific first (i.e. using all three) and then looks for
 >>> a bit less specific (i.e. lang/country and lang/script) and then
 >>> for least specific (i.e. lang). Failing that it returns the
 >>> application default, which does not specify any language, country
 >>> or script.
 >>>
 >>
 >> The C++ sword engine does not do the search for parents as you
 >> explain for Java.
 >
 > Right SWORD looks for exactly what is requested, nothing more. I was
 > suggesting a change to the engine.
 >
 > Without an engine change you have to have file duplication.
 >
 >
 >>
 >> E.g. there is a locale de. Searching for de_DE should bring up de
 >> in absence of de_DE, but this does not happen. I have checked
 >> that.
 >
 > In Java looking for de would never find de_DE. For this, your
 > suggestion of renaming the file is needed. de_DE -> de.
 >
 > However, if a SWORD program only looks for de, it won't find de_DE.
 > The SWORD engine has no fallback.
 >
 > Your suggestion was that a search for de to find de_DE. This goes
 > from the less specific to the more specific and I don't think that
 > makes sense. And it may come up with two choices as with Portuguese.
 >
 >>
 >> But even if we make the engine's search more intelligent (to search
 >> for "parent" if the "offspring" search has failed), we still need
 >> to create duplicate locales for some of the situations where we
 >> have no "parent" locale, just "offspring" -e.g. in Russian and
 >> Arabic.
 >
 > Yes. In the case of JSword, if we only have one choice, Egyptian
 > Arabic, we make that the default, ar. If we know it should not be the
 > default, we also duplicate it as ar_EG. When we get another version
 > of Arabic, we create ar_XX, or rename ar to ar_EG and create ar since
 > XX is a better default.
 >
 > And if you have no fallback mechanism, then you have to do it via
 > file duplication.
 >
 >> Chinese is complicated and I do not know what the right solution
 >> is. Maybe in some places failure is the right answer.
 >
 > For Chinese JSword assumes that \ in mainland China that Simplified
 > is used and Traditional elsewhere.
 >
 > The proper way is to support script and have that work. (Which will
 > be when JSword uses Java 7).
 >
 > So rather than zh_TW and zh_CN you'd have zh_hant and zh_hans.
 >
 >>
 >> Peter
 >>
 >>
 >>
 >>
 >>
 >> _______________________________________________ sword-devel mailing
 >> list: sword-devel at crosswire.org
 >> http://www.crosswire.org/mailman/listinfo/sword-devel Instructions
 >> to unsubscribe/change your settings at above page
 >
 >
 >
 > _______________________________________________ sword-devel mailing
 > list: sword-devel at crosswire.org
 > http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to
 > unsubscribe/change your settings at above page