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