Dan, I wrote it in a clone of the master branch, but it will apply (perhaps with fuzz) to pretty much any version ... the code being touched is ancient.
-- Mike Rylander | Director of Research and Development | Equinox Software, Inc. / Your Library's Guide to Open Source | phone: 1-877-OPEN-ILS (673-6457) | email: [email protected] | web: http://www.esilibrary.com On Mon, Mar 31, 2014 at 12:50 PM, Dan Reuther < [email protected]> wrote: > Mike, > > > > What version of openSRF did you write this patch for? I currently have > 2.2.0. Do I need to upgrade or do you see an issue with the version I have? > > > > Thanks > > > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Mike > Rylander > *Sent:* Tuesday, March 25, 2014 2:08 PM > *To:* Evergreen Development Discussion List > *Subject:* Re: [OPEN-ILS-DEV] ***SPAM*** Boolean Search Feature Questions > > > > Dan, > > > > The code you mention isn't involved (it's not dealing with the layer that > knows about the client-selected locale, and that comment is referring to > the disconnect between MARC-prescribed language codes and > everyone-else-in-the-world locale codes), but I think I see the issue. The > short version is that method_lookup() in OpenSRF does not return an object > that knows about the current session, which is needed to find the locale, > thus the locale is forgotten at that point in the process. Attached is an > OpenSRF patch for you try out ... note that it is entirely untested, but it > should be something in the right direction. The point of it is to create > the OpenSRF::AppSubrequest shim earlier, and stash the session there for > use in the eventual call to run(). > > > > If that works out for you I'll create a launchpad bug and post a > pullrequest branch. OpenSRF 2.4 is planned for Soon(tm). > > > > > > > > On Tue, Mar 25, 2014 at 1:35 PM, Dan Reuther < > [email protected]> wrote: > > This question is in regards to > https://bugs.launchpad.net/evergreen/+bug/1152863 > > > > I am tracking a bug in this implementation and could use some assistance. > The feature seems to work as expected for English language searches. The > problem is when we switch to say French Canadian the operators are not > translated. I admit to not fully understanding how the localization system > works in Evergreen. Does Evergreen currently have the ability to translate > search queries? > > > > The behavior I am expecting is the following. Language is set to en-US > and the user enters book or moon on the Boolean search tab and they > are given the results that match book and the results that match moon. > If the language is set to fr-CA and the user enters book ou moon > they should see the same results. Currently the first works as > expected the second returns no matches. > > > > I set the language to French (Canada) and then trace the locale through > the program. I find that it switches to en-US in > Application::Search::Biblio::multiclass_query. > > > > At line 950 in OpenILS/Application/Search/Biblio.pm I find the following > comments > > > > # XXX This stops the session locale from doing the right thing. > > # XXX Revisit this and have it translate to a lang instead > of a locale. > > #$arghash->{preferred_language} = > $U->get_org_locale($arghash->{org_unit}) > > # unless $arghash->{preferred_language}; > > > > So I am curious if this is a known bug or just an unimplemented feature in > Evergreen at this time and I am chasing a bug for functionality that does > not exist? > > > > Any help would be appreciated. Thanks > > > > > > Dan Reuther > > Developer > > [image: Catalyst Logo] > > > > > > > > -- > Mike Rylander > | Director of Research and Development > | Equinox Software, Inc. / Your Library's Guide to Open Source > | phone: 1-877-OPEN-ILS (673-6457) > | email: [email protected] > | web: http://www.esilibrary.com >
<<inline: image001.png>>
