Currently, cr_items defines the attribute "locale" as
varchar(4) referencing cr_locales(locale). However, locale in
cr_locales seems to be not a "locale" as used elsewhere in OpenACS,
but just a two character language code. Furthermore, the
table cr_locales contains in standard applications only a single tuple:
oacs# select * from cr_locales;
locale | label | nls_language | nls_territory | nls_charset
--------+----------+--------------+---------------+--------------
us | American | AMERICAN | AMERICA | WE8ISO8859P1
(1 row)
The table ad_locales looks much better (defining locale as
varchar(30) containing locales like "en_US", "de_DE"etc.)
and is well populated (61 entries).
In typical OpenACS/DotLrn installations, cr_items.locale is
not used for content items(always null). Interesting
enough, there as an index cr_items_by_locale for this
attribute on cr_items (just adding performance overhead).
Is there some good reason, why this is like this?
It would make much more sense to drop cr_locales and
replace it by ad_locales (or e.g. simply rename
"ad_locales" to "locales", use "locales" instead of
"cr_locales" and provide a legacy view "ad_locales" if
necessary).
Background for this posting:
xowiki uses cr_revisions.nls_language for keeping the
locale. For xowiki, keeping the locale on the revision
level is strictly speaking incorrect. It should be on
the item level, since if there are two entries in
different languages, these are maintained
as different items (for every language, it is possible
to keep revisions of the entries).
The reason why xowiki used nls_language at the first place
was most likely due to the fact that this attribute is the
only language specific attribute in the automatic views
of the content repository types.
By looking closer, the situation is even worse:
"nls_languge" is used for paraphrased language names
in ad_locales, so keeping this in cr_revsions does not
look correct either to me (it should be dropped from
there or changed into something more sane).
My original hope was to simply use cr_items.locale instead
of cr_revsions.nls_language in the forthcoming release
of xowiki, but i realize that there is some preliminary
work necessary for that.
For xowiki, the simplest approach is to stop using
nls_language and either derive the information from the
name prefix on the fly or from an additional attribute in
the type specific table for xowiki pages.
What i don't know:
- are there good reasons for having cr_locales.locale and items.locale as varchar(4)?
- are there good reasons for having cr_locales and ad_locales?
- are there good reasons for keeping nls_language in the revisions table?
-gustaf neumann
