[OPEN-ILS-DEV] 1.4 release: switching locales in the OPAC and
staff client
Mike Rylander
mrylander at gmail.com
Tue Jul 22 17:35:41 EDT 2008
On Tue, Jul 22, 2008 at 2:40 PM, Dan Scott <denials at gmail.com> wrote:
> 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.
The ll_ll form is simply normalized to avoid any case-based confusion.
I'll have to look through the code to make sure there are no
assumptions of _ instead of -, but we can change to '-' notation. If
we provide (which we will) an interface for creating supported
locales, then I suppose I could drop the case folding as well.
I normalize to "lower and _" in the core i18n stored proc and the
split on _ to find generalizations, but I can remove the normalization
if we can accept the constraint (human-imposed) of "don't shoot
yourself in the foot -- use exact matches for local strings" ... which
I suppose we can. :)
--miker
>
> 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
>
--
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
More information about the Open-ils-dev
mailing list