Hi Greg, On Wed, Sep 12, 2012 at 2:06 PM, Greg Hellings <greg.helli...@gmail.com>wrote:
> On Tue, Sep 11, 2012 at 9:52 AM, Jonathan Morgan <jonmmor...@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. > 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 > 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. > 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 add up). Jon > > --Greg > > > > > Jon > > > > > > On Tue, Sep 11, 2012 at 9:33 AM, Greg Hellings <greg.helli...@gmail.com> > > wrote: > >> > >> On Mon, Sep 10, 2012 at 6:00 PM, Peter von Kaehne <ref...@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@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@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@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@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@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
