[OPEN-ILS-DEV] settings-tester.pl libdbi error question
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 [EMAIL PROTECTED] 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@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.
Re: [OPEN-ILS-DEV] settings-tester.pl libdbi error question
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 [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] 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@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
