Re: [OPEN-ILS-DEV] 1.4 release: switching locales in the OPAC and staff client
On Saturday 26 July 2008 9:57 Mike Rylander wrote: On Tue, Jul 22, 2008 at 5:35 PM, Mike Rylander [EMAIL PROTECTED] wrote: On Tue, Jul 22, 2008 at 2:40 PM, Dan Scott [EMAIL PROTECTED] wrote: [snip] After supposing for a few days, here are 2 patches which remove the normalization (there was less than I thought) sprinkled throughout the code. No more lowercasing, but we do change '_' to '-' in the core stored procedure that does the translated value lookup. With these patches in place (they're not yet), it's required that ALL locales be assembled in the ll-LL format (that's not strictly true ... there's just no fudge factor in locale case anymore). Eyeballs apreciated, since they touch python and java in addition to my areas. The Java and Python bits look good. -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] 1.4 release: switching locales in the OPAC and staff client
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 [EMAIL PROTECTED] wrote:
On Tue, Jul 8, 2008 at 11:44 AM, Dan Scott [EMAIL PROTECTED] 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 (
codeTEXTPRIMARY KEY,
marc_code TEXTNOT NULL REFERENCES config.language_map (code),
nameTEXTUNIQUE 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_fieldTEXTNOT NULL,
identity_value TEXTNOT NULL,
translation TEXTNOT NULLREFERENCES
config.i18n_locale (code),
string TEXTNOT 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
Re: [OPEN-ILS-DEV] 1.4 release: switching locales in the OPAC and staff client
On Tue, Jul 22, 2008 at 2:40 PM, Dan Scott [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote:
On Tue, Jul 8, 2008 at 11:44 AM, Dan Scott [EMAIL PROTECTED] 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 (
codeTEXTPRIMARY KEY,
marc_code TEXTNOT NULL REFERENCES config.language_map (code),
nameTEXTUNIQUE 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_fieldTEXTNOT NULL,
identity_value TEXTNOT NULL,
translation TEXTNOT NULLREFERENCES
config.i18n_locale (code),
string TEXTNOT 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
Re: [OPEN-ILS-DEV] 1.4 release: switching locales in the OPAC and staff client
On Tue, Jul 8, 2008 at 11:44 AM, Dan Scott [EMAIL PROTECTED] 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 (
codeTEXTPRIMARY KEY,
marc_code TEXTNOT NULL REFERENCES config.language_map (code),
nameTEXTUNIQUE 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_fieldTEXTNOT NULL,
identity_value TEXTNOT NULL,
translation TEXTNOT NULLREFERENCES
config.i18n_locale (code),
string TEXTNOT 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
[OPEN-ILS-DEV] 1.4 release: switching locales in the OPAC and staff client
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
