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

[Mike Rylander]

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/20140325/887078bd/attachment.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/20140325/887078bd/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: subrequest-with-session.patch
Type: text/x-patch
Size: 1244 bytes
Desc: not available
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20140325/887078bd/attachment.bin>