Spin-off from #605630: Comment language administration UI

We want to store the language a comment was entered in. That language does not need to be editable.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

andypost’s picture

Status: Needs review » Reviewed & tested by the community

Tested with 2 languages and it works

Suppose therу should be follow-up after #533924: Allow different language types to be enabled separately to set language of the content not the interface language

Dries’s picture

Status: Reviewed & tested by the community » Needs review

On my personal blog, some people will post comments in Dutch although I have none of the i18n/locale stuff enabled. So, Dutch comments would be stored as English afaik. At some point, it might be nice to be able to correct that. It seems like that could happen a lot though -- it is not because the interface is in English, that the comments will be in English. Commenters are not trained/educated content editors so I'd expect there to be a lot of clean-up work needed to be done by moderators.

andypost’s picture

FileSize
2.21 KB

This patch just parents language from node->language

I think to solve this we need language-changer for comments in admin somewhere but this task is for contrib.
Default behavior should check node->language then fallback to interface language.
It's not good idea to give user ability to choose a language of the comment form any kind of visual control.

peximo’s picture

In #605630: Comment language administration UI sun say:

Hm, this actually filters by the current global content language, and not by the assigned language of the node.

And I reply:

Yes, because with translatable fields without translation.module the node language is always only one but we can have fields translated; with this patch we can show a node with translated fields depending on the selected content language and filtering the comments for this language.

IMO if a user view a node that "appears" in one language (with translated fields) it's a good idea to set the comment language like the content language and not the node language.
EG. a node with nid 1 has node->language = en and a set of fields translated to italian. If i get /it/node/1 the content of the node (the fields) is showed in italian. So IMO the comments are italian too more easily than english.

andypost’s picture

Anyway the $comment->language shell be assigned at comment_form() stage and not in comment_save() because comment_save() could be used in triggers\actions staff.

So in my patch I use $comment->language in both insert and update

peximo’s picture

FileSize
2.56 KB

Ok, with this we have $comment->language like in previous (andypost) patch and the content language instead of node->language.

sun’s picture

+++ modules/comment/comment.module	15 Oct 2009 22:33:04 -0000
@@ -1852,6 +1854,10 @@ function comment_form($form, &$form_stat
+  $form['language'] = array(
+    '#type' => 'value',
+    '#value' => isset($comment->language) ? $comment->language : $node->language,
+  );

If we go this route, then we should use the global $language->language here, I guess, or not?

I'm on crack. Are you, too?

peximo’s picture

I agree with sun. The last patch use $language->language.

andypost’s picture

FileSize
2.49 KB

If you trying to use global $language so it should be defined

plach’s picture

Issue tags: +translatable fields
andypost’s picture

FileSize
2.92 KB

Now with upgrade path

catch’s picture

Status: Needs review » Reviewed & tested by the community

This looks great.

I think we should evaluate whether we want to mass-update the comments table on update with the language of the node they were posted on, if that's already set. However that requires a lot of thought and might not be desirable. I tested the upgrade path and it worked fine, did a describe on comments to verify everything was in place.

We need an index on language - but we need to have a query using it first to see if it's nid, status, language or just language or whatever, so let's discuss that in a (critical) followup issue.

andypost’s picture

FileSize
3.03 KB

This is a patch with index, because we dont really know what kind of queries will be run I use nid+language for #605630: Comment language administration UI

Suppose we can add more indexes latter as follow-ups

sun’s picture

I agree.

catch’s picture

Status: Reviewed & tested by the community » Needs work

Need to add the index in comment_schema() too.

andypost’s picture

Status: Needs work » Needs review
FileSize
3.25 KB

Oh, changed schema

catch’s picture

Status: Needs review » Reviewed & tested by the community

That's it. Please wait for green from test bot before committing.

webchick’s picture

Status: Reviewed & tested by the community » Fixed

I understand Dries's concerns at #2, but I'm not sure what we can do about this, really... at least in core. Short of presenting a language selector to the user to choose which language their comment is posted in, which strikes me as a UX nightmare to figure out.

On IRC catch pointed out two things:

1. A contrib module could also hook into google translation API or whatever for assigning languages once the storage property is there.
2. Comment module currently deletes all child comments without warning, even if flat comments, and lets users click any reply link they want. Posting in a different language is the least of our worries.

;)

I'm inclined to agree. This patch looks pretty straight-forward to me.

Committed to HEAD. Though Dries, if you feel strongly about this, obviously feel free to roll-back.

Status: Fixed » Closed (fixed)
Issue tags: -translatable fields

Automatically closed -- issue fixed for 2 weeks with no activity.