[sword-devel] Locale differences

[Jonathan Morgan]

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).

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?

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20120912/34f12869/attachment.html>