Find a way to handle linking content in other language even if i18n rewrites queries

It should display all nodes regardless of node or interface languages.
Maybe it has something to do with the way i18n is configured on your site.
Can you provide more information?

I will have a look at this.

Is there any solotion for this? I have the same problem :/

same problem for me too

@all: can you please post all your locale/i18n related settings?
Thanks!

It was a mistake on my part : when I tested it I was looking for a page of an another language, so I didn't find it.
I did not understand the behavior of this module : it shows only pages of the current language, that is the logical behavior.
Now if I was in the same language of the page I was looking for, it is shown in the list.
So actually there is no problem with the module for my side ! Sorry for my mistake.

Actually, CKEditor Link does not perform any kind of language filtering by itself.
It simply relies on your site settings to show only the nodes the user has access to.
This is the role of db_rewrite_sql at line 43 in the .module file.
So you should have a look at your locale/i18n settings.
For instance, on the sandbox, it is possible to link to both contents in FR and EN, isn't it?

This is due to your Content selection mode (admin/settings/language/i18n), not the CKEditor Link module.

Using the content selection mode of i18n only makes sense if you also have the "Switch interface for translating" option set. In that case then you will get a list of content in the same language as the current node. If that option is off then it is possible to edit non-English nodes in the English interface language but not be able to access the content you need.

On my website we do not use "Switch interface for translating" so I need this module to behave differently.

I've attached a patch which changes the query if that option is disabled. It serves my needs and I believe it is a sensible behavior.

Sorry, forgot to change status.

I can't reproduce this behavior. Please list your i18n settings.

On the sandbox at http://www.absyx.fr/en/sandbox, it is possible to link to both contents in FR and EN, isn't it?
Yet, "Switch interface for translating" is not set.

My content selection is set to "Current language and language neutral" (stored as "simple" in the i18n_selection_mode variable).

I guess the solution would have to check that variable and adjust accordingly. The only content selection mode which would be guaranteed to return results in the language of the node being edited is "All content. No language conditions apply." (stored as "off" in the i18n_selection_mode variable).

My preferred behaviour is to return results only of the same language as the node being edited. For my website it would never be desired to link to a page of a different language. That is also why I had content selection set to only current language or language neutral.

Here is an updated patch which takes content selection mode into account though it may not be satisfactory if you wish to always see all content and not just the same language content.

This issue still exists in the 2.x branch. Do I need to redo the solution for the 2.x branch? This is a critical need for multilingual sites.

@tangent:
What do you think is a bug here? Please describe:
- what you're trying to do
- what you expect
- what you actually get
Plus, list *all* your i18n settings.

The government website that I manage must offer all content in 2 languages. Editors work with content of both languages but the interface is configured to use the language of your choice. i18n settings are the following:

i18_selection_mode: "simple" (Current language and language neutral)
i18n_translation_switch: 0 (Do not switch interface for translating)
i18n_newnode_current_CONTENTTYPE: 1 (Set current language as default for new content)
i18n_required_node_CONTENTTYPE: 1 (Require language (Do not allow Language Neutral))
language_negotiation: 3 (Domain name only)

The behavior that I see with these settings is the following.

1. While using Drupal with an English interface language, edit an English language node. Create an internal link. Only english nodes are listed in the autocomplete list.

2. While using Drupal with an English interface language, edit a French language node. Create an internal link. No nodes can be found.

3. While using Drupal with a French interface language, edit a French language node. Create an internal link. Only french nodes are listed in the autocomplete list.

4. While using Drupal with a French interface language, edit an English language node. Create an internal link. No nodes can be found.

The behavior in #2 and #4 is a bug, in my opinion.

CKEditor Link should select nodes based on the language of the node, and not the language of the interface, with the i18n settings specified above. This may be difficult to handle for new nodes (the autocomplete field would have to pass the current value of the language field as an argument).

If any other i18n settings are required to reproduce what I am experiencing let me know.

@tangent: thanks for your detailed information.

CKEditor Link should select nodes based on the language of the node, and not the language of the interface, with the i18n settings specified above. This may be difficult to handle for new nodes (the autocomplete field would have to pass the current value of the language field as an argument).

This part is a feature request: I want to add it too so stay tuned about it.

Currently, CKEditor Link is designed to work this way: it lists nodes no matter what languages they have. If it does not, this means that i18n alters the way nodes are queried in some way.
Based on the information you provided, I will carry some tests this week-end and let you know. I may ask you some extra info if needed.

Could you just tell what i18n modules and versions you use so that I use the same? Thanks.

Block translation (i18nblocks) Module Enabled 6.x-1.10
CCK translation (i18ncck) Module Enabled 6.x-1.10
Content type translation (i18ncontent) Module Enabled 6.x-1.10
Internationalization (i18n) Module Enabled 6.x-1.10
Menu translation (i18nmenu) Module Enabled 6.x-1.10
String translation (i18nstrings) Module Enabled 6.x-1.10
Synchronize translations (i18nsync) Module Enabled 6.x-1.10
Taxonomy translation (i18ntaxonomy) Module Enabled 6.x-1.10
Views translation (i18nviews) Module Enabled 6.x-2.x-dev

@tangent: all right, I understand your problem.
Unfortunately, this has nothing to do with CKEditor Link itself but with the way i18n rewrites queries based on its own settings: @see i18n_db_rewrite_sql()
And see #8: CKEditor Link does not perform any kind of language filtering by itself.

So there is no bug here: CKEditor Link can't prevent any other module from rewriting its queries. And db_rewrite can't be removed because it would bring a security issue.

So we need to think about a way to handle this case. But IMHO changing ckeditor_link.node.inc is not the solution. We should add an extra ckeditor_link.i18n.inc that would support this feature.

I will also have at i18n itself to see if it's possible to get the expected behaviour by changing its settings.

If CKEditor supported views then this issue could be easily resolved at the views level. There are many more benefits to supporting views (e.g., configurable sorting, adding additional fields, changing result limit) but requiring CKEditor Link to depend on Views to resolve the i18n requirement might be undesirable.

There are probably many ways to approach this requirement so I'm glad you are interested in doing it. I would likely not come up with the approach you will take.