Support nodes translated with Entity Translation

Todo delete, wrong post

Dear Mainteners,

when is this patch going to be merged into the public version?
I've applied this patch manually (thx plach) and it works as I expected, but it would be better not to have the patch manually applied but included in the public version. Is there any reason why this patch is not yet accepted?

Regards,
Dexx

I've seen it working only in a very basic situation. Based on that, I wouldn't be brave enough to say it works perfectly for every situation :) So it would be good if other people could verify if this patch works for them too or not.

Patch #1 works for me, thank you. :)

Patch #1 works for me, tested on 4 multilang sites with entity translation

Patch #1 works for me too, thank you

Patch #1 is working well for me. Thank you for developing this.

Updated issue summary.

See next post ..

I have attached an updated patch that don't throw warnings like :

"Notice: Undefined property: stdClass::$type in ckeditor_link_ckeditor_link_node_url()"

... if the content contains dead links.

Hi,

looks I'm doing something wrong, using

- Entity Translation 7.x-1.0-beta3
- CKEditor Link 7.x-2.3 with patch #13 or #1
- CKEditor 7.x-1.3 (with CKEditor 4.3)

When I type three characters in the autocomplete field, nothing appears when editing a translated node.
When I do the same in de default language, it works.

Anyone any idea what I'm doing wrong?

Thanks

We're using patch from comment #13 in production now for several months; Works very good.
Can someone please commit?

Here is a patch which solves the autocomplete problem, the correct node path will be returned

Another patch which corrects the shown path when reopening the link popup

#13 worked for me.

#18 provides a languages prefix in the url.
But when creating a link to an entity translated node, I need the url to be 'node/00' and not 'en/node/00', so the url will stay within the same language version. Or am I missing something?

Same patch (#18), correct file path.

I expanded autocomplete query to be able to search translated titles. Similar modifications added to node_revert too.
Merged previous changes into this patch.

I'm Using Version 7.x-2.3 and also with patch #22 the autocomplete in entity translation was not showing the correct Titles in the current language.

I've checked the Query in ckeditor_link_ckeditor_link_node_autocomplete() and made some changes.

For example the search in n.title was there twice but it has only to check if it's in n.title or then in t.title_field_value.
WHERE (n.title LIKE '%TITLE%') AND (n.type IN ('TYPE') AND( (n.title LIKE '%TITLE%') OR (t.title_field_value LIKE '%TITLE%') )
is now
WHERE (n.type IN ('TYPE') AND( (n.title LIKE '%TITLE%') OR (t.title_field_value LIKE '%TITLE%') )

I also changed the return result for matches. It used to show all translated Titles of the Node in Autocomplete, but in my opinion, there only must show the titles in the current language.

Please feel free to correct me or my patch.

Thanks for review and suggestions.

I reviewed my patch again, query is correct. My patch removes line ->condition('n.title', '%' . db_like($string) . '%', 'LIKE')
How did you applied patch?

There could be cases where link should point to node other than current language. Maybe we need some global variable to switch.

@rudins
Maybe it didn't remove the line because i'm using the 7.x-2.3 Version?!

#22 is working fine for me. Would be nice to make a stable release with it.

Here is the same patch as in #22, but without appending language code to node title.
Line

<?php
 $label = $node->title_field . ' (' . $langcode . ')';
?>

is now just

<?php
 $label = $node->title_field;
?>

I think it is obvious that when editor want to add link to the node he do not want to show that langcode after node title (in most cases).

#22 works for me too. I prefer to keep the language code that was removed in #27. It adds clarity, and is useful in cases where a node has been translated but its title has not yet been changed.

Any chance this patch is going to be merged into the public version?

If the i18n_node module is used, the language code is not shown in #22. I added the language code when entity_translation is not installed, but i18n_node.

In my opinion, it would be better so show the language code to prevent mistakes. Sometimes you have two nodes in two similar language versions with the same title, but the body text is different, e.g. german and swiss-german or us-english and british-english .

@Unicycle:
There are plenty of patches here. Which one should actually be committed?

#27 works for me. Thanks undertext!

Changing category to Bug report because module page says: 'Full multilingual support' but this issue is not mentioned.

About current pacthes:
#22 seems to address the issue.
#27 is the same as #22 but not adding language code to the title (just for informative reasons).
#30 is the same as #22 but showing language code even if i18n_module is not installed.

I think the language code appended to title feature must be discussed. If accpeted, #30 is the right patch, if rejected the #22 is the one to go.

I'm not sure about #23, it says that corrects an issue in #22 but #22 is working for other users.

Hi,
Patch #22 is working for me too. Thanks.

@Note: When using this module in combination with pathologic I'm having some issues (just for the record, if anybody is trying this patch you better disable other modules filters).

There is a problem with the latest patches: they assume that every node title is replaced using the Title module. I have one use case where the title of a node type is untranslatable (person name), whereas other types' titles are translatable. Those nodes can't be linked.
Here's the patch, upon #27.

I have applied patch #13 against 7.x-2.4 again.

We are building a large multilingual website with 18 language and having all translated node titles appear in the autocomplete field, doesn't make thing easy to find with many language activated.

Maybe it would be a good idea to make it optional if translated node titles are included in the autocomplete field or not.

What do you think ?

#22 works for me!

Hello, this doesnt working, if you have default language different from english and english has a prefix en - then urls become with /en/en path and its wrong.

edit, patch working if you disable pathologic module.

#30 works perfectly for my i18n-enabled project. I think this patch is more relevant than #22, since it covers i18n-projects as well (thus no extra patching is required for multilingual projects). Modules and patches only covering one language can be quite frustrating and is discouraged by the standards I guess. The language code shown regardless of the fact that the internationalization module is being used doesn't bother me.

EDIT: cheered too early, looking up nodes works, but the output (after saving) doesn't use the url alias. In other words: the CKeditor Link filter is not being honoured (d7.43, php 5.6.2).

I changed the patch from #27 to take into consideration only nodes when joining with the field_data_title_field table:

$query->join('field_data_title_field', 't', 't.entity_id = n.nid');
$query->condition('t.entity_type', 'node'); // this was missing

I noticed this issue because ckeditor_link_ckeditor_link_node_revert() was returning the title of an entity (not a node) with the same id of the node it was searching for.

Added the language code before the label for autocomplete matches.

Patch looks good, including an interdiff with #27 which was RTBC.

I think the only point of contention is whether to add the language code for entity translated nodes or not (see #27, #28, #42) -- people seem to think it's useful, so back to RTBC for #42.

Hi,
IMHO, the language code is important and adding it before the label for autocomplete can help the editor to create the link. The patch #42would be very useful.
When do you think you will commit it?
Thank you.

Ste

I can confirm that the patch from #42 works. The language prefix in the titles at the autocomplete results are very helpfull. This way a user is not forced to link only nodes in the current language and it helps the user when the titles in both languages are the same or very similar (which could happen with Dutch vs English language).

I would vote for commiting patch #42 into the next release.

Cheers,
Bram.

I encountered the same problem and the patch #42 works perfectly.
Agreed for this patch in the next release, it is written "Full multilingual support" in bold on the main page of the module, so it's quite confusing when it is not working correctly. I thought I missed something in the configuration.

Thanks a lot for your help.

Patch #42 doesn't work in quite popular scenario, when one of the languages has empty prefix (no prefix) set.

When you'd like to link to prefixed language from non-prefixed language content, all works fine.

When you'd like to link to non-prefixed language from prefixed one - it will incorrectly add current language prefix.

I believe fix should be somewhere inside ckeditor_link_path_strip_language

My quite dirty hack here:

function ckeditor_link_path_strip_language($path, &$langcode) {
  $languages = ckeditor_link_get_languages();
  if ($languages) {
    $args = explode('/', $path);
    $prefix = array_shift($args);
    foreach ($languages as $language) {
      if (!empty($language->prefix) && ($language->prefix == $prefix)) {
        $langcode = $language->language;
        $path = implode('/', $args);
        return $path;
      }
    }
    //separate language sweep for non-prefixed languages (reachable only if previous returned no results) 
    foreach ($languages as $language) if ($language->prefix === "") {
      $langcode = $language->language;
    }
  }

  return $path;
}

Thanks for the patch!

I did run into a problem with pathologic, and I found mpark's and TuWeBo's comments on it.
The site's front-end broke entirely (browser showing connection_reset error) after enabling the ckeditor link filter and returned to normal after disabling it.

Uninstalled pathologic and works as a charm. I'm not sure if its safe to commit this just yet, unsuspecting users could encounter problems when updating.