I think your suggestion makes sense. It is how we do it in JSword. Several places I've run into the need to have a designation beyond lang: Portuguese (Portugal vs Brazil), Chinese (Traditional vs Simplified) and Arabic (Egypt vs ???). In the case of Chinese it is a script difference, but the others are language variations by country/region.
Should the Description follow what we have said for a module's conf, where the
Description is the localized version and Description_en is the English version?
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.
If it is given less to start (e.g. lang/country, lang/script, or lang) it picks
up at that point in the fall back.
In this scheme ru_RU would never be found by someone in ru_ZZ. So it is
important to establish a less specific, language only file. It may be important
have remarks in the file indicating specificity. For example, Portuguese.
In Him,
DM
On Jan 3, 2014, at 10:22 AM, Peter von Kaehne <ref...@gmx.net> wrote:
> Would there be any objection if I do following:
>
> 1) Many of the description lines of our locale files have the language
> name in long form with an added "(Unicode)"
>
> e.g. ru_RU-utf8 reads as follows:
>
> [Meta]
> Name=ru_RU
> Description=Russian (Unicode)
>
> I see no good reason that the "(Unicode)" is there. Users do not need to
> know this, programmers know what they are doing. I would like to delete
> this bit from all relevant files, so that it only reads as follows:
>
> [Meta]
> Name=ru_RU
> Description=Russian
>
> 2) We have a whole bunch of locales with added country codes, but
> without default locale for the language. As a result doing the following
> (C++) fails:
>
> LocaleMgr *localeMgr = new LocaleMgr();
> SWLocale *modlocale = localeMgr->getLocale("ru");
>
> while
> LocaleMgr *localeMgr = new LocaleMgr();
> SWLocale *modlocale = localeMgr->getLocale("ru_RU");
>
> will succeed. I think this is overspecific and should not be so.
>
> Unless there is a fix possible in the engine which would result that
> localeMgr->getLocale("ru") calls "ru_RU" I think we should simplify our
> locale provision so that all locales are named without country code,
> unless a specific country code gives extra information. I.e here i would
> copy/move the file ru_RU-utf8.conf to ru-utf8.conf and recreate a
> ru_RU-utf8.conf only if we wanted to create alternatives for e.g.
> ru_KAZ, ru_RU and ru_UK etc.
>
> Any objections or suggestions to this?
>
> Peter
>
>
>
>
> _______________________________________________
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
