Hi Greg,<br><br><div class="gmail_quote">On Wed, Sep 12, 2012 at 2:06 PM, Greg Hellings <span dir="ltr"><<a href="mailto:greg.hellings@gmail.com" target="_blank">greg.hellings@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Tue, Sep 11, 2012 at 9:52 AM, Jonathan Morgan <<a href="mailto:jonmmorgan@gmail.com">jonmmorgan@gmail.com</a>> wrote:<br>
> For the record, BPBible allows the locale for book names to be selected<br>
> independently from the locale for the user interface (though it will default<br>
> to being the same). From memory this was added to handle the case where<br>
> book names were available for another language but no one was ever likely to<br>
> translate BPBible into that language. It seems to also have fallback to the<br>
> default SWORD book names (e.g. English).<br>
<br>
</div>This is the exact scenario I find myself in. Does BPBible allow that<br>
to be selected on a per-module basis? For instance, I would love to<br>
work this one minority language module in its native but I do all the<br>
rest of my work in English.<br></blockquote><div><br></div><div>It's a global setting, not module-specific.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
><br>
> I've considered allowing it to use book names for the module language as<br>
> well as the current locale, but have never actually implemented it and so<br>
> have not considered which way to prioritise it. A possible issue is if you<br>
> have one reference box which controls multiple linked windows in different<br>
> languages (e.g. two Bibles or a Bible and a commentary). Would we expect<br>
> the app to parse references in any of the languages present in any of those<br>
> windows?<br>
<br>
</div>An intriguing possibility. Xiphos is almost always working two windows<br>
- scripture and commentary - which need not bear any relation to one<br>
another. BibleTime is able to turn any Bible window into a<br>
multi-module window by adding another Bible or Commentary. I would<br>
expect it to understand all available languages, though I'm not sure<br>
how much good that would actually do. But it also bears considering<br>
that if I have two modules open, one in English and one in German<br>
let's say, and I click on a reference that is not in osisID format,<br>
can an application properly parse such a reference from both modules<br>
or will one of them get booted to Revelation 1:1? Such a scenario<br>
provides a possible reason that all dictionaries - at least of opened<br>
modules - be considered. Order would, of course, need to be dictated<br>
in some way.<br></blockquote><div><br></div><div>It's always fun trying to guess what would make sense to a "normal" user.</div><div><br></div><div>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).</div>
<div><br></div><div>Jon</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
--Greg<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> Jon<br>
><br>
><br>
> On Tue, Sep 11, 2012 at 9:33 AM, Greg Hellings <<a href="mailto:greg.hellings@gmail.com">greg.hellings@gmail.com</a>><br>
> wrote:<br>
>><br>
>> On Mon, Sep 10, 2012 at 6:00 PM, Peter von Kaehne <<a href="mailto:refdoc@gmx.net">refdoc@gmx.net</a>> wrote:<br>
>> > On 10/09/12 20:44, Greg Hellings wrote:<br>
>> ><br>
>> >> I just wanted to put that out here, so there is a record of it and so<br>
>> >> developers for either app can think about the UX they want. In the<br>
>> >> case of Takwane, since neither application has a Takwane locale it is<br>
>> >> likely the users will try for Portugese in the application's UI but<br>
>> >> will still want to type their native Takwane book names. This makes<br>
>> >> Xiphos' UX undesirable as it only understands English and whatever<br>
>> >> locale the UI is in. But presumably a user might want to open a module<br>
>> >> in a different language and still be able to use their native locale<br>
>> >> (like us English speakers are probably used to doing since the engine<br>
>> >> appears to understand English all the time). This makes BibleTime's UX<br>
>> >> bad because it seems to ignore the UI's locale.<br>
>> >><br>
>> >> I'm unsure of a path to take when recommending an application to the<br>
>> >> translators for testing because of this. Both situations could be<br>
>> >> awkward, unless they eventually decide it is worth the effort to<br>
>> >> translate the UI itself into Takwane.<br>
>> ><br>
>> > The effort to translate the user interface is not huge - an evening<br>
>> > rough, a weekend really nice.<br>
>> ><br>
>> > But I agree nevertheless. There is a problem.<br>
>> ><br>
>> > Many minority languages will not warrant a GUI translation and in many<br>
>> > places it might even not be desirable as people are not used to use<br>
>> > computers in the minority language, but use a computer in the main<br>
>> > national language.<br>
>> ><br>
>> > I guess exposing the search locale as an user defined option and adding<br>
>> > the ability to have several search locale might be the best way forward.<br>
>><br>
>> Are you thinking like a set of radio buttons, or a combo box that<br>
>> lists the UI locale and the module locale (and possibly all available<br>
>> locales) which the user could select? It looks like Locale can be set<br>
>> dynamically on an SWKey directly, so it would allow this to be a<br>
>> setting that affects each module individually or the entire<br>
>> application, depending on choice.<br>
>><br>
>> That seems like a reasonable choice to me, but it's probably worth<br>
>> discussing which should be the default: the module's Lang or the UI's<br>
>> lang. That's probably a choice that each application needs to decide<br>
>> when they decide what mechanism to use to specify the active locale.<br>
>><br>
>> --Greg<br>
>><br>
>> ><br>
>> > Peter<br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
>> > <a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
>> > Instructions to unsubscribe/change your settings at above page<br>
>><br>
>> _______________________________________________<br>
>> sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
>> <a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
>> Instructions to unsubscribe/change your settings at above page<br>
><br>
><br>
><br>
> _______________________________________________<br>
> sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
> <a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
> Instructions to unsubscribe/change your settings at above page<br>
<br>
_______________________________________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br>
</div></div></blockquote></div><br>