[sword-devel] Locale differences
jonmmorgan at gmail.com
Wed Sep 12 02:09:01 MST 2012
On Wed, Sep 12, 2012 at 2:06 PM, Greg Hellings <greg.hellings at gmail.com>wrote:
> On Tue, Sep 11, 2012 at 9:52 AM, Jonathan Morgan <jonmmorgan at gmail.com>
> > For the record, BPBible allows the locale for book names to be selected
> > independently from the locale for the user interface (though it will
> > 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
> > 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.
It's a global setting, not module-specific.
> > 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
> > have one reference box which controls multiple linked windows in
> > 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
> > 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.
It's always fun trying to guess what would make sense to a "normal" user.
So long as you don't have references which parse as different books in
different locales, it should be relatively innocuous to try a locale and
find it doesn't have a match (though from memory we found that SWORD took a
non-zero time to switch locales - not necessarily significant, but it would
> > 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>
> >> > 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
> >> >> 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
> >> >> 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
> >> > the ability to have several search locale might be the best way
> >> 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
> sword-devel mailing list: sword-devel at crosswire.org
> Instructions to unsubscribe/change your settings at above page
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the sword-devel