[sword-devel] Locale differences

[Greg Hellings]

On Tue, Sep 11, 2012 at 9:52 AM, Jonathan Morgan <jonmmorgan at gmail.com> wrote:
> For the record, BPBible allows the locale for book names to be selected
> independently from the locale for the user interface (though it will default
> to being the same).  From memory this was added to handle the case where
> book names were available for another language but no one was ever likely to
> translate BPBible into that language.  It seems to also have fallback to the
> default SWORD book names (e.g. English).

This is the exact scenario I find myself in. Does BPBible allow that
to be selected on a per-module basis? For instance, I would love to
work this one minority language module in its native but I do all the
rest of my work in English.

>
> I've considered allowing it to use book names for the module language as
> well as the current locale, but have never actually implemented it and so
> have not considered which way to prioritise it.  A possible issue is if you
> have one reference box which controls multiple linked windows in different
> languages (e.g. two Bibles or a Bible and a commentary).  Would we expect
> the app to parse references in any of the languages present in any of those
> windows?

An intriguing possibility. Xiphos is almost always working two windows
- scripture and commentary - which need not bear any relation to one
another. BibleTime is able to turn any Bible window into a
multi-module window by adding another Bible or Commentary. I would
expect it to understand all available languages, though I'm not sure
how much good that would actually do. But it also bears considering
that if I have two modules open, one in English and one in German
let's say, and I click on a reference that is not in osisID format,
can an application properly parse such a reference from both modules
or will one of them get booted to Revelation 1:1? Such a scenario
provides a possible reason that all dictionaries - at least of opened
modules - be considered. Order would, of course, need to be dictated
in some way.

--Greg

>
> Jon
>
>
> On Tue, Sep 11, 2012 at 9:33 AM, Greg Hellings <greg.hellings at gmail.com>
> wrote:
>>
>> On Mon, Sep 10, 2012 at 6:00 PM, Peter von Kaehne <refdoc at gmx.net> wrote:
>> > On 10/09/12 20:44, Greg Hellings wrote:
>> >
>> >> 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.
>> >
>> > The effort to translate the user interface is not huge - an evening
>> > rough, a weekend really nice.
>> >
>> > But I agree nevertheless. There is a problem.
>> >
>> > Many minority languages will not warrant a GUI translation and in many
>> > places it might even not be desirable as people are not used to use
>> > computers in the minority language, but use a computer in the main
>> > national language.
>> >
>> > I guess exposing the search locale as an user defined option and adding
>> > the ability to have several search locale might be the best way forward.
>>
>> Are you thinking like a set of radio buttons, or a combo box that
>> lists the UI locale and the module locale (and possibly all available
>> locales) which the user could select? It looks like Locale can be set
>> dynamically on an SWKey directly, so it would allow this to be a
>> setting that affects each module individually or the entire
>> application, depending on choice.
>>
>> That seems like a reasonable choice to me, but it's probably worth
>> discussing which should be the default: the module's Lang or the UI's
>> lang. That's probably a choice that each application needs to decide
>> when they decide what mechanism to use to specify the active locale.
>>
>> --Greg
>>
>> >
>> > 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
>
>
>
> _______________________________________________
> 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