[OPEN-ILS-DEV] ***SPAM*** RE: Boolean Search Feature Questions

[Mike Rylander]

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:  miker at esilibrary.com
 | web:  http://www.esilibrary.com

On Mon, Mar 31, 2014 at 12:50 PM, Dan Reuther <
dReuther at catalystitservices.com> 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:* open-ils-dev-bounces at list.georgialibraries.org [mailto:
> open-ils-dev-bounces at list.georgialibraries.org] *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 <
> dReuther at catalystitservices.com> 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:  miker at esilibrary.com
>  | web:  http://www.esilibrary.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20140331/83d8082b/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 11795 bytes
Desc: not available
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20140331/83d8082b/attachment-0001.png>