Forum OpenACS Improvement Proposals (TIPs): TIP #66: (Approved) Standards for Internationalizing Content
ProposalThe following changes will be made to the OpenACS data model:
- In OpenACS 5.2, cr_items will be changed to use the ad_locales table instead of the cr_locales table. Sample code for PostGreSQL:
alter table cr_items drop constraint cr_items_locale_fk; alter table cr_items add constraint cr_items_locale_fk foreign key (locale) references ad_locales;
- The cr_locales table is deprecated for OpenACS 5.2, and will be removed in OpenACS 6.
- All internationalizable content is stored in the content repository
- Localized versions of content are stored as cr_items, separate from the original cr_item
- cr_items which are localized versions of other cr_items are related in the database. (Original Proposal: cr_items which are localized versions of other cr_items have a cr_child_rel relationship to the original item, with the relationship type "localized")
- There can be only one localized child per item per locale.
- If the original item is not in a published state, none of its localized versions are published.
- If a localized child is not in published state, the original item is not available for that locale.
- If a parent item has children, all of those children must also be published in a specific locale before the item can be considered available in a specific locale. If an item is published in a locale but not all children are published in that locale, the item should be identified as "partially available" and developers can choose whether or not to treat it as published.
- Localized cr_items have their own internal versions just like all cr_items. To have two different versions of an original item that have independently maintained and published localizations, you must use two different items.
- There is a mechanism to determine if the original item has been changed since the most recent publication of a localized version. This can be used to notify authors or to automatically de-publish obsoleted translations.
- API functions listing items should exclude by default items which are translations of other items on the same list.
- Whenever a function would normally return the title or content of a cr_item, the internationalized form of such a function should instead return, in descending order of preference:
- The title and/or content from the live version of the "localized" version of the original item in the locale specified to the function, if available.
- The title/content from the live version of the "localized" version of the original item in the default locale for the language of the specified locale, if available.
- The title/content live version of the original cr_item.
OpenACS does not provide a standard way to internationalize content, and so different implementations are using different workarounds. This TIP will provide a standard for new implementations and for upgrades to existing implementations.
DisadvantagesThe data model change will ultimately break any existing code which depends on cr_locales. There is no such code in the standard modules, so this is much outweighed by the benefit of removing duplicative but incompatible tables.
I will implement the data model changes in OpenACS 5.2. Packages which use the content repository will not qualify for Maturity Level 3 until compliant with this TIP.
This is the second version of this proposal. All comments prior to 16 June 2004 refer to the first version. The change has been made in place for ease of reading.
I think the items should use a cr_item_rel instead of cr_child_rel.
Also, did we decide to leave out the storage of a "translation tree" in case a translated item was not translated from the original, but from one of the other translations?
I think a "translation" rel could be an optional convention used when needed, but I didn't feel like I really understood how it would work or how to manage its complexity. So I didn't want to put it into the TIP and I didn't want to hold the TIP up waiting for enlightenment.
So to rephrase my other question: disregarding translation vs localization issues, what's the difference between a cr_item_rel and a cr_child_rel? Is there currently any API in cr_items that uses either? If not, is there any guidance on how they are intended to be used, so that if that basic API ever gets built as intended, the data already in the system will be correct?
But it does not. They are all peers. One is just the "original" I think cr_child_rel is for compound content items where the children are parts of one big item. So a "page" might be made up of several content items. So for a compound item each translation could would have it's own children.
The issue is that someone might want to know what language an item was translated from. I think you are correct that this is probably more application specific and does not need to be part of this TIP.
I agree with Dave, it should be cr_item_rel. We have actually changed our design in of our project from cr_child_rel to cr_item_rel. We are implementing it right now. The reason why we decided to use cr_item_rel is that localized items must be able to exists even if the parent item is deleted. The items are peers and should not be parent-child relation.
The other aspect that Dave is mentioning is keeping track how things where translated. Its essentially a different TIP as Dave mentions. Essentially we have a requirement and should also be useful in general to keep track things where cloned for translation purposes for historical reasons.
Under what conditions would the original item be deleted?
If the original item is deleted, how will you find the other localizations for that item?
I'd probably go for a single anchor item that contains or is parent of the translations for that item. Delete this anchor implies deleting all the translations: what reason would they have to exist otherwise? if a localization did exist, how would you find the other localizations when that's necessary?
Thanks after the OCT chat we are looking at implementing just that. One "container" item with each translation as a child. I think we want to try a quick implemetnation and see if any issues come up before finalizing the translation linking.
Perhaps we should appprove the datamodel changes seperate from the APis and rules to manage translations?
I believe there is no question that the items should use ad_locales table.
I think its possible to have one translation to be deleted. There will be cases that a site will just get a common base of content and use its own translated content on its own. So I believe we can't discount that its possible to delete the original item where the translation came from.
That is why I and Dave is asking to make things more of peer level rather than parent child relationship. This way when the original item is deleted the remaining translation can still find its peers.
plenty of yesses and no no votes.