Translate OG group nodes

Yes, this is a known issue. I'm going to ask the i18n folks how the imagine this working. We don't even have a vision for this ATM.

@pieter,
> Am I the first one having this problem? (I hope I don't)

Actually you're the first one I hear of.

Groups are not something people usually don't think of as multilingual, as all the content sharing features don't really make too much sense then, unless you add also different content (and separation) within the group for the different languages, which takes us one level higher...

Anyway, I'd like to hear about how can you imagine it working. I.e. you subscribe to a group, then you get all the content for that group in all the languages? or if you get it in one language only, why not making different groups then?

There are some related issues (WIP) that could actually make the group localizable once implemented, but still that's not a solution for these questions... There's this one and another one about 'localizing some node fields', #293297: Translation of labels and values for CCK fields

Anyway, moving to i18n queue, I think it makes more sense there.

I understand your 'legal' requirements (I live in a country with 4 official languages) but from a practical point of view it doesn't really make too much sense to me.

Only a government could think of a multilingual working group working :-)

Anyway, if you want this working, there are some features that need to be implemented first, that would allow us to 'localize' nodes. And in general I think we better focus on specific features as 'Translate OG groups' is quite a generic and vague one, so feel free to add yours to the list.
#293297: Translation of labels and values for CCK fields
#313840: Support for translation of some node strings

To implement this with the currently existing features, a different approach may be to have different groups (for each language) and a 'group of groups' that would hold all the translated groups and posts. And maybe when translating posts belonging to a group automatically populating the group it belongs too with the original group's translation. This also can be translated into specific feature requests either for OG or for i18n.

For D7, we might want to change og_ancestry so that we affiliate translation sets with groups, instead of nodes. That would help avoid the duplication of posts that we face when we affiliate all translations with the same group. We might also consider the group node as a translation set so that we get the multiple description thing. A lot of this depends on how the i18n sprint goes and if we do fieldable for translation sets.

I really like the idea of moshe.
I think if og groups wouldn't be nodes that'd make og more flexible.

tracking

I am facing this exact issue on two projects we are working on. As I won't be able to wait for D7, I need to figure out which solution to pursue now. Going via the localisation route (as described in the issues Jose mentions) or trying to come up with an OG module to do what Moshe is talking about (or something like it).

For former seems wrong as, I believe, fixing a spelling error in the source string would result in lost translations (and doesn't it pollute the locales table?). So I'd prefer the latter, but if Moshe is talking about D7 he must have a good reason... gulp.

In the meantime, I'll open this issue back up (since it was auto-closed anyway). I hope that that is OK.

Omar

I don't want to be a pain here but I don't see why this was set to "fixed". Not only have neither of the issues mentioned been resolved, AFAICT neither addresses the problem described; specifically the need for translations of "group nodes" to NOT be treated as separate groups. The first is about content type labels and values rather than, say, translating the values in the nodes themselves. The second mentions "node strings", but then doesn't provides any solution or path to a solution (unless Im missing something... if so sorry). And, besides, the second one is about using strings/localisation which just seems like a bad approach.

If I can get a clear idea from either the i18n project or the OG project as to the most elegant solution for the problem in D6, I can probably get some code happening.

I can't really contribute much here. I gave some ideas about how this could be solved. They are pretty large changes, so thats why I mention D7. I think Jose or Gabor or catch could provide more info.

i'd like to see if i can work on this issue.

group translation options
- create a group for each translation
- create a single group for all translations

jose, could you give me some hints how to implement this functionality?
maybe we could do this by allowing to syncronize og specific fields.

dasjo take a look at what sun said here http://drupal.org/node/282178#comment-1599214
Especially interesting could be the possibility in D7 to have translatable fields "...And, some of these are in line with recent discussions on translatable fields during a i18n core sprint, where we identified that D7 might be able to support translated content without separate nodes, but using field translations instead."

daniel, thank you for the link - i talked to nedjo and he gave me some hints how to create a patch which allows to synchronize og-specific fields.
based on his patch for the nodereference sync
http://drupal.org/node/301736#comment-985947

on a long term view, field translations instead of node duplication per translation to me seems a good aproach - d7

for the redesign of www.c3mundos.org, nedjo and i just created a quick fix for this issue.

the patch changes og_set_group_context so that "Translated group nodes refer to their translation source as group node."
also it changes nodeapi insert and update so that "Translated group nodes won't be treated as groups because we only use the translation source as group."

missing features
- rewrite group links and titles to the current viewed translation node (eg. group block)
- patch doesn't provide a configuration options (create a group for each translation, create a single group for all translations)
- sync audience field for group posts

thank you for providing feedback or even better implementing missing features

dasjo thank for your patch and like what you say is still incomplete. I not a programmer so can't help much but will there be a complete patch or any plan to work with i18n?

Subscribing...

I believe this issue should be closed as the problem has since been dealt with by the i18n module.

To have an OG group node translatable, you must ensure the proper settings have been selected in the content type form:

• Multilingual support: Enabled, with translation. - This setting gives you a nice link in the local node menu options so you can readily get the job done.
• Multilanguage options:
  • Options for node language: Pick the most appropriate setting for your setup.
  • Extended language support: Pick the most appropriate setting for your setup.
  • Synchronize translations: This is always an important part of the setup, for most purposes, I suspect, if you have a taxonomy, the Taxonomy Terms checkbox should be checked. The others, unless you require each field of the node to be synchronized between translations, I would leave them to their default states.

I hope this helps those who find this ticket.

NOTE: The Audience field is not included in the Multilanguage Synchronize Translations fieldset. This may still need to be reviewed.

@wilco
I can't see how the options you mentioned solves the problem being discussed here.

I have been asked to come up with some sort of reasonable solution to this problem. This problem has many little bits that make this a difficult issue.

The attached patch was originally based on #15 and grew from there.

This patch adds a checkbox option to the node type "One group for all translations".

This patch includes fixes for:
- Group node links
- Group block title
- Audience options
- og home view node list
- removes group related form fields on translations

The bulk of this patch has to do with translating node titles. The best example of this is the audience options. With patch #15 only source groups appear but if a translation exists I need to use the translations title.

I don't know if this is the best way of doing things but it seems to work for me.

Note:
- This patch was developed on 6.x-2.1
- I also use active translations and there is one small part of this patch that requires this patch http://drupal.org/node/886840 and could be ignored or removed in future revisions of this issue.

I hope somebody finds this useful.

This is an updated version that fixes a few issues with first version.

Changes:
- greatly improved translation method/function
- don't alter node object, only alter the options and links when being displayed

could someone post the og.module file with this patch applied?

Sorry, but i tried learning how to patch earlier and what a pain! little patches done manually is no problem, but this one was too long and confusing so i gave up. Thanks!

My way of getting around this is simple.

All my groups nodes are "language neutral" with no translation

any posts under that will be english or arabic (with translation)

all i need is to create a translated page that has the Page contents in the the other languae and link to it from the Group node

everyone joins a single Group node regardless of language. Awkward translation link for the Group Node as it would be a manually generated one and embedded in the Group node content in HTML

I've gone over the patch, although it should be re-rolled with some changes, and please make sure it re-rolled in a way that the function names appear, so it's easier to review it.

I have recently finished doing the same thing in OG7. The biggest change in the patch should be having a function og_get_group($nid) -- that returns the _correct_ node ID. The patch should include calling this API function whenever it is needed, instead of doing the translation check all over. Some other things, from a quick review:

+++ og.module	Fri Jan 16 05:21:36 1970
@@ -1731,6 +1762,18 @@
+      if (module_exists('active_translation')) {
+        $at_mode = active_translation_mode();
+        active_translation_mode('off');
+      }

This doesn't belong in the patch.

+++ og.module	Fri Jan 16 05:21:36 1970
@@ -2462,4 +2522,87 @@
+ * Helper function;

Helper function to do what? Docs are needed.

+++ og.module	Fri Jan 16 05:21:36 1970
@@ -2462,4 +2522,87 @@
+  return $node->tnid != 0 && $node->tnid !== $node->nid ? TRUE : FALSE;

Enough to write return $node->tnid != 0 && $node->tnid !== $node->nid;

Powered by Dreditor.

#20
@NaX

Can you give a quick example showing the translation process for a Group using your patch?

@maximer
Node translations works the same as always (Translate Tab), the only difference is that the patch tries to change all node NIDs were needed to the source node NID (first translated group node) and were needed display the relevant node content EG: show node title for relevant language.

So as an example.
If you have a group were the source node is in English and a user adds a post to the French translation the audience selection form item will display the French group title but the English source nodes NID is used. This way all nodes are posted on the source nodes NID. The same applies to the create node links in the group block. The gids that are passed to the node create from are the source node's NID.

When viewing a translated group node the source group node NID is used to create the node/post lists by passing the source NID to the view as an argument rather than its own NID.

After completing this patch I had an idea that it would better if OG added a get source group function that returns the source nodes ID similar to what Amitaibu was saying in #24. This function can then expose a hook so that we can allow other modules to handle the translation lookup process IE: i18n. The og_group_is_translation() function sort of server this purpose in the patch with the help of the og_group_array_translation() function.

This function should then be called when ever needed EG: node links, node_load, node forms. The hardest part of this patch was finding every place this would be relevant, especially when you have limited knowledge of OG. The thing that took me a while to figure out and messed me around the most was the og_node_groups_distinguish() function. You have to disable and then afterwards re-enable content negotiation, else the db_rewrite_sql() function call returns the translated nodes and because I use Active Translation I added the ability to turn off Active Translation as well. It would probably be better if i18n exposed a hook or action for when its mode changes so we don't have to support other modules like Active Translation.

One thing to keep in mind is that I have not tested this patch without the Active Translation module. When developing the patch I tried to not use any functionality that Active Translation provides, but I might have missed something.

Amitaibu: I'm just looking at cleaning up this patch as I will need this functionality in a new project.

Can you clarify your comment about needing a function og_get_group($nid)?

I'm assuming you mean to use this function every where og uses a groups $nid?
Do you think og_get_group should return a node object or just the group gid?

I haven't had a look yet but I'm guessing this would also need to be used in all supporting OG modules too? (ie. og_user_roles?)

Right. I should have read that issue more clearly. Thank you for identifying this. I was under the impression it worked fine as long as nodes for each language existed. I now see how the problem could have been an annoyance.

subscribing.
I'm looking for a way to synchronize users subscriptions to a Organic Group that was created in multiple languages. Currently they have to subscribe to one OG for each defined language. There is no option available to have users subscriptions synced.
Thanks for looking into this.

subscribe

My issue is that group is set to language neutral but the node which belongs to a group is set to multilingual (en and de)
Now, the link "create_node" in groupe detail block cannot be translated because group has been set to language neutral.
So my question is; how to make this link translatable in both languages en and de

this issue seems to be fixed already in 7.x branch, can we close it???

Is this fixed in 7.x? I just created a group and a translation for the group, and my "Group Audiences" field shows both groups. Although I haven't gotten to the point of creating content and group members and testing, it certainly doesn't appear that it's going to treat this like a single group. Maybe it works with entity translation? (Another thing to test.)

Groups are not something people usually don't think of as multilingual, as all the content sharing features don't really make too much sense then...

...from a practical point of view it doesn't really make too much sense to me.

@Jose - since you posted that more than two years ago, it may now make more sense to you, but if not, here's a use case as to why such a feature is needed:

I'm building a site for a bilingual immersion school and would like to use OG to give each grade a space to share information. Having a group called "Spanish-speaking First Grade Families" and another called "English-speaking First Grade Families" would be antithetical to the mission of the school. What we need is a single group called "First Grade," where all information can be posted in both languages (or posted by a momolingual parent and then translated by someone else), encouraging everyone to contribute, and perhaps improving their second language skills at the same time.

I think we can summarize the functional requirements here in two:
1. Being able to translate groups but still being the same group.
2. Limit the available languages for content in a group.

About 1.

To have the same group (node or other entity) being translatable you'll need http://drupal.org/project/entity_translation The bad news is this is only available for Drupal 7. So we should mark this as "won't fix" for Drupal 6.

About 2.

OG would need to support setting not one, but multiple languages to a group.
Then i18n provides a hook for being able to limit the list of translation languages available for a node. See i18n_node_language_list(), the og module would need to implement that hook_language_list() for nodes.

Then you may need some more group related UI widgets, like a language selector for group content, etc. So I'd suggest someone creates and maintain some new og_i18n or i18n_og module for Drupal 7.

Thanks Jose. I'll switch my translation method to entity translation (I'm in D7). Glad to know that will solve problem #1.

Adding tag.

I installed entity translation, and the fields of the group translate fine, but not the group entity title.
Anyone a solution for that?

@Yuri, entity translation doesn't seem relevant to a D6 issue :)

Since OG 7.x-2.x is back to where the NID is used as the group id, therefore, the same question stands: How to translate the Group node content without creating two separate Organic Groups?

One possible solution: like Flag module, it offers the two options:

Flag translations of content as a group
Flag each translation of content separately

Should OG detects the translation and override the group id with the translation source NID?

> How to translate the Group node content without creating two separate Organic Groups?

You can't do it with 2.x. That's a feature (which I don't think many if anyone used) that was dropped in favor of simplicity.

An undocumented feature is a bug.

Dropping gid in 2.x is great for simplicity (save a lot of work for views relationship).

However, without sacrificing the design of simplicity, can we do something to support this feature or fix the bug?

For example: On the content type editing page, OG offers a checkbox, saying "treat the translations of the group content as a single group".

Then, modify the OG CRUD to detect these i10n group node.

I agree with @skyredwang that this is a useful feature — I made a case in #31 for why someone would want to have a single bilingual group. However, as long as this is achievable using Entity Translation, I wouldn't advocate for a return to the separate nid/gid system; I have found version 2.x infinitely easier to configure so I think the simplicity is worth some compromise.

That said, Entity Translation may not be an option for everyone, so if implementing a solution like the one suggested in #39 were a possibility, I think that would be a great improvement for this module. In the meantime, I'm going to pursue a relatively content-free, language neutral group node solution like the one @firebug is using in #22.

Follow my comments #37 and #39, why don't we implement hook_node_translation_change(node), provided by Translation helpers

It should be a simple patch and we can borrow it from Flag Module?