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

[Mike Rylander]

On Tue, Jul 8, 2008 at 11:44 AM, Dan Scott <denials at gmail.com> wrote:
> 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?

I'm unsure, at this time, of the best way to provide a precedence list
of locales in any given situation, but I think it's important that
this all be stored in the database.  To that end, I've created a new
table and fkeys among existing tables:

-- new table
CREATE TABLE config.i18n_locale (
    code        TEXT    PRIMARY KEY,
    marc_code   TEXT    NOT NULL REFERENCES config.language_map (code),
    name        TEXT    UNIQUE NOT NULL,
    description TEXT
);

-- available locales
INSERT INTO config.i18n_locale (code,marc_code,name) VALUES
('en_us','eng',oils_i18n_gettext('American English'));
INSERT INTO config.i18n_locale (code,marc_code,name) VALUES
('en_ca','eng',oils_i18n_gettext('Canadian English'));
INSERT INTO config.i18n_locale (code,marc_code,name) VALUES
('fr_ca','fre',oils_i18n_gettext('Canadian French'));
INSERT INTO config.i18n_locale (code,marc_code,name) VALUES
('es_us','spa',oils_i18n_gettext('American Spanish'));
INSERT INTO config.i18n_locale (code,marc_code,name) VALUES
('es_mx','spa',oils_i18n_gettext('Mexican Spanish'));

-- added fkey constraint
CREATE TABLE config.i18n_core (
    id              BIGSERIAL   PRIMARY KEY,
    fq_field        TEXT        NOT NULL,
    identity_value  TEXT        NOT NULL,
    translation     TEXT        NOT NULL    REFERENCES
config.i18n_locale (code),
    string          TEXT        NOT NULL
);


Note that this makes config.language_map table the center of the
natural language universe, with multiple locales pointing at the
language codes held there.  The requirement is, then, any language for
which we provide an interface translation must be a valid language in
whatever metadata standard used by the system ... today, of course,
that means MARC21.  Doesn't seem too restrictive, given nearly
distinct language codes currently available. :)

The locale names and descriptions are i18n ready and the dev database
has been updated with these changes.

>
> 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
>

I'm not sure about this order.  In particular, the OpenSRF gateway (as
of version 1.0) implements Accept-Language stiffing now, which means
that the org and system settings won't be used unless the user has
gone to the trouble of unsetting their language pref.  (That is
assuming I'm not insane, and my browser did install itself with my
default locale (en-US) as it's default Accept-Language  setting ...
which is what I believe to have happend.)

-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / The Evergreen Experts
 | phone: 1-877-OPEN-ILS (673-6457)
 | email: miker at esilibrary.com
 | web: http://www.esilibrary.com