[sword-devel] Locale differences
dmsmith at crosswire.org
Mon Sep 10 18:01:31 MST 2012
This is a hard question. And a good one.
For the record (not saying it is right or that it is best or even good) here is how JSword does it:
It does not use the Locale of the module.
It uses the OSIS book names first. (Assumes that the majority of Book Names come from OSIS modules)
Then it uses the user's Locale. (Assumes that the Locale is meaningful for the user.)
Finally it uses English book names. (Fall back for ThML and GBF and for consistency.)
You didn't mention what happens if you have an inexact match. I'd have to look in the JSword code to see what happens if it doesn't find the input. The fall back is to look for the input as a proper prefix or as an alternate name or abbreviation. But I forget whether it looks for an exact match first across the three dictionaries and then for proper prefixes in the latter two and then for the alternate name in the latter two. Or whether it exhausts one level before the next. JSword doesn't order like SWORD does. It prioritizes first by NT, then by OT, and within the testament by book order.
The results of inexact matches depend on the ordering of the matching algorithm.
We've thought about using the module's language. And we/ve thought about doing lookups over all dictionaries of Book Names. But what order?
Just not clear on what actually makes sense.
On a side note, the locale we use:
The locale of the chosen translation. (It might make sense to also have a list of known languages that the user can select and order. But we don't do that.)
If that is not set, then we use the locale that the user chooses via their OS and is exposed in Java as Locale.getDefaultLocale();
We don't use the LANG environment variable unless that is the OS mechanism.
On Sep 10, 2012, at 3:44 PM, Greg Hellings <greg.hellings at gmail.com> wrote:
> Just wanted to note here some differences between Xiphos and BibleTime
> locale handling.
> I'm working with a new, minority language translation. The language is
> Takwane with the language code abbreviation "tke". I have successfully
> created a module which has the conf file entry "Lang=tke" and began to
> note some oddities about locale handling. For ease of reading further,
> "Wambeela" is the Takwane name for Genesis and "1. Mose" is how the
> book name appears in our German locale.
> In Xiphos, when I start the application with my default locale of
> LANG=en_US.UTF-8 and open the Takwane module, the application properly
> understands only the English names of books and ignores the Takwane.
> That is, I can type in "Genesis 2:1" and be properly navigated to that
> position but entering "Wambeela 2:1" causes the application to ignore
> my input. To test, I started the application with LANG=de, and I could
> type EITHER "Genesis 2:1" or "1. Mose 2:1" and I would navigate to the
> appropriate passage. If I started the application with LANG=tke I
> could enter either "Genesis" or "Wambeela". Thus, Xiphos ignores the
> Lang setting on the module and only understands the LANG environment
> In BibleTime I started the application with my en_US.UTF-8 locale and
> opened the Takwane module. Here, the module understood both "Genesis"
> and "Wambeela". Setting LANG=de and restarting the application causes
> it to still understand "Genesis" and "Wambeela" but it can't grasp "1.
> Mose" and instead punts me to "Rev 1:1" for a parsing error.
> Appears to ignore the LANG variable, but cannot parse the module's
> address without using the "-l tke" switch.
> So it appears that the engine will always comprehend English book
> names and that BibleTime is somehow honoring the module's Lang setting
> but ignoring its own UI setting while Xiphos is honoring the
> UI/environment setting but ignoring the module's Lang setting.
> I just wanted to put that out here, so there is a record of it and so
> developers for either app can think about the UX they want. In the
> case of Takwane, since neither application has a Takwane locale it is
> likely the users will try for Portugese in the application's UI but
> will still want to type their native Takwane book names. This makes
> Xiphos' UX undesirable as it only understands English and whatever
> locale the UI is in. But presumably a user might want to open a module
> in a different language and still be able to use their native locale
> (like us English speakers are probably used to doing since the engine
> appears to understand English all the time). This makes BibleTime's UX
> bad because it seems to ignore the UI's locale.
> I'm unsure of a path to take when recommending an application to the
> translators for testing because of this. Both situations could be
> awkward, unless they eventually decide it is worth the effort to
> translate the UI itself into Takwane.
> sword-devel mailing list: sword-devel at crosswire.org
> Instructions to unsubscribe/change your settings at above page
More information about the sword-devel