We had a problem with using og & i18n last year. Caused us to write an og_translate module to ensure that the list of objects under an organic group was the same in both French & English. There were only two fields that needed to be translated, so it wasn't a huge undertaking. We're running into the problem again when trying to extend the events module to include conference registration information.

There are many instances when you would want to have the text a user sees change but the summaries that an admin sees be be aggregated. For a trivial instance it would be useful to see page counts summarized for both languages, rather than having to jump back/forth between the french & english pages to see how many people are visiting.

We need to know that when someone registers for an event on the english side or on the french side that reporting for the number of participants, lists of participants is clearly for one event and not two.

There needs to be some way link fields between translated nodes so that they cannot be updated independently. An easy example of a field that should be locked in the events module is the start/end dates. It is too easy for this to be changed for one side and not for the translated node. Most users wouldn't assume that the date would need to be adjusted in both places since it doesn't actually require translation.

Has anyone done any work on fixing fields between translated nodes?

Mike

Comments

steve.m’s picture

steve.m commented

There are a bunch of node types where creating a second version of the node to handle i18n breaks functionality - groups and events come to mind. A translation of a group shouldn't be a second group; likewise with events.

In some ways this isn't an i18n module issue -- it's more of a "module developers need to think about i18n" issue. I envision a patch to Events, say, that does something like this:

- test for the presence of i18n
-- if present, test for a translation of the node in question (nodeA)
--- if present, constrain its SQL queries using "nodeA OR nodeB" rather than just nodeA

This would return the aggregated information about both nodes, but treat them as a single event. And similarly for OG.

Feasible?

jose reyero’s picture

jose reyero commented
Status: Active » Closed (won't fix)

There are some features in newer versions: field synchronization, multilingual polls (6.x)... No new features for 5.x though.

mgifford’s picture

mgifford
he/him
Primary language English
commented

Thanks for the update Jose. Happy New Year!