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

[Dan Scott]

Hi Mike:

The database location is good. Is there any reason you chose to go
with the "ll_ll" form for language/region in the code field, rather
than the "ll-LL" form currently used for translations? The latter form
is also used by Dojo, which would be handy for locazing dates, times,
and currencies.

On 19/07/2008, Mike Rylander <mrylander at gmail.com> wrote:
> 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
>


-- 
Dan Scott
Laurentian University