[OPEN-ILS-DEV] 1.4 release: switching locales in the OPAC and staff client

[Dan Scott]

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