Forum OpenACS Q&A: Re: RFC: How to internationalize content

Joel,

I am not aware of any existing code that uses the cr_revisions.locale information.

One possibility to support custom applications we are not aware of would be to add cr_items.locale and wait one release cycle to remove cr_revisions.locale.

Jun,

I think the "localized" tag makes more sense, and it won't affect our plans.

One use case that is not addressed is determining which localization of an item was used to translate from. I think this is applicaiton specific and can be accomodated by recording this additional relationship seperately. I think it is necessary to tie all localized items to one "master" content_item. This makes it efficient to show a list of all localized versions of an item. An example would be if an item was origianlly written in english, then translated to french, and subsequently was translated from french to german.

There actually already is a cr_items.locale.  The only problem is that it's a Foreign Key to cr_locales.locale, which is varchar(4), whereas ad_locale.locale is varchar(30) and in practice contains only five-character strings.  The upshot is that the upgrade should be really easy.  We just have to change the fk to use ad_locale, and figure out how to handle any data currently using cr_locales.  How about just doing a one-time mapping from the initial values of cr_locale.locale to those of ad_locale.locale, and throwing an error back to the upgrader for locales not in the mapping?  I'd like to get this into 5.2.