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

[Robert Soulliere]

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.