[OPEN-ILS-DEV] settings-tester.pl libdbi error question

[Dan Scott]

Hi Robert:

First and foremost, if your system is running okay then you can simply
ignore the error message.

Second, the story (as uncovered by Dan Wells) is that libdbi-drivers
changed in release 0.83 so that the old --enable-libdbi flag that used
to be required to link the drivers to the libdbi.so library now does
the exact opposite. So depending on your version of libdbi-drivers,
you may or may not have to use the --enable-libdbi flag. We probably
need to update Makefile.install accordingly.

Dan

2008/7/9 Robert Soulliere <robert.soulliere at mohawkcollege.ca>:
> I am getting the error when running settings-tester.pl:
>
> "/usr/local/lib/dbd/libdbdpgsql.so was not linged against libdbi - you
> probably need to compile libdbi-drivers from source with the --enable
> -libdbi configure switch."
>
> I thought this question came up in the past and tried to find a solution
> in past Evergreen-Dev posts but could not so I apologize if I am
> bringing up a old issue which has already been discussed.
>
> I tried to do what following the instructions indicated on:
> http://open-ils.org/dokuwiki/doku.php?id=libdbi
> to no avail.
>
> Is there another problem here I should look into? I am running Evergreen
> version 1.2.1.4 on a Debian Linux server.
>
> Thanks,
> Robert
>
>
>
>
>
> ----- Original Message -----
> From: Dan Scott <denials at gmail.com>
> Date: Tuesday, July 8, 2008 11:45 am
> Subject: [OPEN-ILS-DEV] 1.4 release: switching locales in the OPAC and
> staff client
> To: Evergreen Development Discussion List
> <open-ils-dev at list.georgialibraries.org>
>
>> Thoughts on the following proposal for the (rapidly approaching)
>> 1.4 release?
>>
>> I'm particularly interested in the plumbing for supported & default
>> locales. We could conceivably have one set of locales supported for
>> the OPAC, and a different (probably smaller) set of locales supported
>> for the staff client. And corresponding to that, a staff user might
>> prefer to use the OPAC in one locale, but use the staff client in a
>> different locale (probably because the corresponding translation isn't
>> available in the staff client). This is trickiest to manage if we do
>> opt to support a "locale preference" at the user level; but one way
>> might be to implement locale preference as a fall-through list akin to
>> how browsers do it, so if a given locale isn't available the next one
>> is automatically tried.
>>
>> Related issue: I don't think there's a way of expressing a supported
>> set of locales in the system. And the default locale is currently
>> hard-coded as en-US.  Would it make sense to beef up opensrf.xml to
>> include a <locales> element within <default> (possibly with a list of
>> <supported_locale> child elements and a single <default_locale> child
>> element) and teach the various libraries to rely on that? Or would it
>> make more sense to push those settings into the database where we can
>> provide a user-friendly admin interface?
>>
>> Hmm. Part of me likes the database approach, as it means that we could
>> have an actor.org_unit_setting override the system-wide default locale
>> (in our consortium, some libraries are French-only, others are
>> English-only). But perhaps that particular problem would be best
>> handled via Apache configuration anyways (as the library would
>> probably use a different URL entry point to get to the OPAC).
>>
>> Sorry, I started rambling there. Hopefully this is more helpful
>> rambling than hurtful.
>>
>> ====
>>
>> In 1.4, the OPAC interface will be fully supported in multiple
>> locales.
>> Currently, the locale is determined by the URL, with supported locales
>> and the default locale set in eg_vhost.conf. For example:
>>  * en-US (http://biblio-dev.laurentian.ca/opac/en-
>> US/skin/lul/xml/index.xml)  * fr-CA (http://biblio-
>> dev.laurentian.ca/opac/fr-CA/skin/lul/xml/index.xml)
>>
>> For the production release of the i18n support for the OPAC, we need
>> to add a user-friendly locale switcher mechanism in the OPAC.
>>
>> The switcher should expose:
>>  * the list of supported locales (defined in opensrf.xml?)
>>  * the associated locale name displayed in the language of the
>> respective locale
>>
>> It would be nice if the preference were sticky across sessions (likely
>> via a cookie).
>>
>> We may also want to expose this as a user preference in "My Account";
>> that could also drive other language / locale selections for tasks
>> like generating overdue notices. We cannot rely solely on "My Account"
>> because most users will be accessing the OPAC unauthenticated.
>>
>> Suggested priority of locale selections (where subsequent levels
>> override the previous):
>>  * System default locale (set in eg_vhost.conf? or in opensrf.xml?)
>>  * Org unit default locale (set in actor.org_unit_settings? or
>> perhaps just based on Apache configuration)
>>  * [http://www.w3.org/International/questions/qa-lang-priorities
>> User-agent locale preference sniffing]
>>  * My Account preference
>>  * OPAC locale switcher UI / cookie
>>
>> --
>> Dan Scott
>> Laurentian University
>>
>
>
> This E-mail contains privileged and confidential information intended
> only for the individual or entity named in the message.  If the reader
> of this message is not the intended recipient, or the agent responsible
> to deliver it to the intended recipient, you are hereby notified that
> any review, dissemination, distribution or copying of this communication
> is prohibited.  If this communication was received in error, please
> notify the sender by reply E-mail immediately, and delete and destroy
> the original message.
>



-- 
Dan Scott
Laurentian University