When language fallback is disabled and I'm on the default drupal front page or in a taxonomy term page I see a message that says Español translation unavailable for . for each nodes that are not translated in spanish.

I think that untranslated nodes should not be listed.

I made a patch to do that.

I tested this patch only in front page and taxonomy term page, there's probably other cases.
There's a small hack in this patch (IMO) because query conditions in node.module are not prefixed by node table alias. See : #1452642: PDO Exception when implement hook_query_node_access_alter

#13 entity_translation-dont_list_untranslated_nodes-1452820-13.patch3.45 KBMohammed J. Razem
PASSED: [[SimpleTest]]: [MySQL] 681 pass(es).
[ View ]
#5 entity_translation-dont_list_untranslated_nodes-1452820-5.patch3.13 KBnikosnikos
PASSED: [[SimpleTest]]: [MySQL] 62 pass(es).
[ View ]
#4 entity_translation-dont_list_untranslated_nodes-1452820-4.patch2.2 KBtorpy
PASSED: [[SimpleTest]]: [MySQL] 62 pass(es).
[ View ]
#2 entity_translation-dont_list_untranslated_nodes-1452820-2.patch2.19 KBtorpy
PASSED: [[SimpleTest]]: [MySQL] 62 pass(es).
[ View ]
dont-list-untranslated-nodes.patch2.11 KBnikosnikos
PASSED: [[SimpleTest]]: [MySQL] 62 pass(es).
[ View ]


Component:Code» Base system
Status:Needs review» Needs work

This should be at very least an optional behavior. However supporting the core entity listings is not very interesting as long as we can replace them with Views.

Froma quick look: comments are not wrapping properly at column 80 (see http://drupal.org/coding-standards#comment).

new2.19 KB
PASSED: [[SimpleTest]]: [MySQL] 62 pass(es).
[ View ]

I agree, this should be optional. However, I desperately needed this for a project I'm working on and cleaned it up a little. It fixed up an issue where my content-linked menu items kept appearing even when they didn't have translations for a certain language.

Also: cleaned up the comments/code and fixed issue in patch where non-string condition fields were being evaluated as strings (and consequently erroring out).

Status:Needs work» Needs review

dont-list-untranslated-nodes.patch queued for re-testing.

new2.2 KB
PASSED: [[SimpleTest]]: [MySQL] 62 pass(es).
[ View ]

Minor fix, one of the conditions was too ambiguous.

new3.13 KB
PASSED: [[SimpleTest]]: [MySQL] 62 pass(es).
[ View ]

Here's the same patch with an option in entity_translation admin page to display unavailable message or not.

Thanks for your help nikosnikos. Unfortunately, I was busy with some other aspects of translation problem, so I didn't check the patch. I should try it in next days, because it's important to have choice not to show untranslated nodes. Keep in touch.

Something went wrong here:

patching file entity_translation.admin.inc
Hunk #1 FAILED at 18.
1 out of 1 hunk FAILED -- saving rejects to file entity_translation.admin.inc.rej
patching file entity_translation.module
Hunk #1 succeeded at 387 (offset -248 lines).

Patch works if you apply the hunk that failed manually. The settings work and the warning message dosen't show up anymore. However it seems to only be working for nodes. Using a node index (search api module) through views will still show the warning message.

well, the entity_translation.admin.inc has changed a lot, so it's impossible to apply the patch. I've tried to do it manually, but had some severe errors as a consequence.

But this is really something that has to be implemented in new version of ET.


Sorry, I've just noticed that the error was not due to the patch (event if more testing is needed), but there's this message that is outputed on some of pages when the language fallback is unchecked:

Notice: Undefined variable: entity in _eva_extract_entity_from_build() (line 148 of /var/www/sites/all/modules/eva/eva.module).
EntityMalformedException: Missing bundle property on entity of type node. in entity_extract_ids() (line 7539 of /var/www/includes/common.inc).

I think that I've already published this issue. This is probably somehow related to eva module.

Replaced EVA with the latest dev and the error disappeared. But still, the patch is not functionnal even if I get the checkbox for displaying the unavailable translation message.

There's no difference unchecking or checking. It needs to be updated IMHO.

Status:Needs review» Needs work

NW based on previous comments.

Status:Needs work» Needs review
new3.45 KB
PASSED: [[SimpleTest]]: [MySQL] 681 pass(es).
[ View ]

Patched against the latest dev version 7.x-1.0-alpha2+116-dev

Also rewrote the checkbox's label and description for a clearer behaviour.

Hi, thanks for the new patch.
It seemed that it was getting what we want. Yes, non translated nodes or "no translation available" messages appear no more.

Unfortunately, it's also messing up with the menu ( for some unknown reason, some items disapeared ) and views, blocks listings.

I think the misbehaviors reported in #15 might be caused by the langauge selection feature. Please try to disable it and report.

You mean Internationalization Multilingual Select ?
That module has been disabled since I started using ET. They're not compatible.

Status:Needs review» Needs work

That module has been disabled since I started using ET. They're not compatible.

I thought they were not compatible in certain situations (like this one), not always. Needs work, then.

I didn't test all the situations. But as far as I'm concerned, I had to disable it. For the simple reason that translated nodes are not found in menus and views. We can suppose that as i18n module works with duplicated nodes for translations, lang selection submodule fails to work when translations are in the same node.

And that's why this patch is so important. We need ET to do the job the Multil.Select can't do.


I applied the patch in #13 on the last dev #130. It almost worked for me but not completely yet. Here is some feedback :

What did work :
- untranslated nodes with warning do not appear on taxonomy term pages anymore. Great!
- untranslated nodes with warning do not appear on views lists anymore. Cool too !

What did not work :
- untranslated nodes are still accessible from the node displayed in the source language via the language switcher. The "no available translation" warning appears on the node when switching to an untranslated language. It would be great if the language link could be disabled and crossed (French) like with content translation when the translation does not exist yet.

Faulty behavior caused :
- on node types that still use content translation (i.e. one node for each language) the translation interface is broken when applying the .module part of the patch. Actually the translation mechanism also is broken because when you switch language you stay on the same node and get the "no available translation" warning instead of being redirected to the translated other node.
- on the admin/content page, nodes whose node type still uses the content translation only appear in the source language. If I remove the patch and clear caches I see each node for each language as I should.

For example I still need my Webform site "Contact us" form to be translated with content translation...

PS : the problem occurs only when the patch is applied AND the fallback language is disabled.

Actually the patch causes even bigger problem as this morning I realized I couldn't access my website as an anonymous user anymore.
When I removed the patch and cleared the cache I was able to access it again. I tried to apply the patch again and cleared the caches, couldn't access anymore again.
Here is the error stack that was displayed :

PDOException : SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'EXISTS (SELECT na.nid AS nid FROM node_access na WHERE (( (na.gid = '0') AND (' at line 2: SELECT n.nid AS nid, n.type AS type, n.uid AS uid, n.status AS status, n.title AS title, n.language AS language FROM {node} n INNER JOIN {entity_translation} et ON et.entity_id = n.nid AND et.entity_type = :node WHERE (n.tnid = :db_condition_placeholder_0) AND (n. EXISTS (SELECT na.nid AS nid FROM {node_access} na WHERE (( (na.gid = :db_condition_placeholder_1) AND (na.realm = :db_condition_placeholder_2) )OR( (na.gid = :db_condition_placeholder_3) AND (na.realm = :db_condition_placeholder_4) )OR( (na.gid = :db_condition_placeholder_5) AND (na.realm = :db_condition_placeholder_6) )OR( (na.gid = :db_condition_placeholder_7) AND (na.realm = :db_condition_placeholder_8) ))AND (na.grant_view >= :db_condition_placeholder_9) AND (n.nid = na.nid) )) AND (et.language IN (:db_condition_placeholder_10, :db_condition_placeholder_11)) AND (et.status = :db_condition_placeholder_12) ; Array ( [:db_condition_placeholder_0] => 76 [:db_condition_placeholder_1] => 0 [:db_condition_placeholder_2] => all [:db_condition_placeholder_3] => 0 [:db_condition_placeholder_4] => content_access_author [:db_condition_placeholder_5] => 1 [:db_condition_placeholder_6] => content_access_rid [:db_condition_placeholder_7] => 1 [:db_condition_placeholder_8] => forum_access [:db_condition_placeholder_9] => 1 [:db_condition_placeholder_10] => fr [:db_condition_placeholder_11] => und [:db_condition_placeholder_12] => 1 [:node] => node ) in translation_node_get_translations() (line 489 in myhiddensiterootpath/modules/translation/translation.module).

I have Entity Translation enabled on a website.

The language switcher shows a link for all languages (three enabled) even though many nodes are only available in two languages. For For these nodes the language switcher should hide the language (link) for which there is no translation.

Are there any solutions to this issue?

I tried the language detection settings for both language switchers (UI and Content) but could not get that working.

Am I missing something in configuring the language system or is there a limitation.

All the best,
Guy Saban

In ET settings, you have to uncheck "enable language fallback".

But the problem is that in a place of the non-translated node you're going to have a message saying that translation is not available for it. And the ultimate issue is that you can't hide it.

There were some attempts to solve it, but it didn't really work.

We're all waiting for some work around or a complete solution for this. No way to know if someone is working on it.

And the ultimate issue is that you can't hide it.

It's generated by a theme function: you just need to override it and return an empty value.

AFAIK no one is working on this.

If I understand well, it means that this is not going to change, except maybe for drupal 8 ???

I'm sorry but this is not even remotely among my top-priority issues. For D8 we will have views instead of custom listings, so it will just be matter of adding a language filter.

Ok, thanks for informing us. But, as you said: "It's generated by a theme function: you just need to override it and return an empty value."
Therefore, it shouldn't be something that costs lot of time and effort to be fixed?

This issue is about filtering untranslated nodes from listings, I was offering a solution to hide just the warning. I'll be glad to commit a worhty patch, but the current one is in needs work status and I have no time to improve it.

Plach, thanks for you reply.

I hope the following questions will also help others trying to deal with this issue.

1) I switched off the language fallback at: /admin/config/regional/entity_translation

2) I did some checking and need a little guidance on how to properly implement your approach of the theme override you mention.

It's generated by a theme function: you just need to override it and return an empty value.

3) I enabled devel theme developer module to find the theme function you mention.

I found: links__locale_block() and theme_link()

I assume the links__locale_block() is the one to use in the template.php file.
I also found http://drupal.org/node/1308598 which describes a similar approach but not for the same purpose.

I my case, nodes with entity translations have en & es language translation set and some have es & it language translations set.
This means that I need to check each node for its available language translations. But I always get back all three when I print the $var['links'] that are in the scope of the function links__locale_block().

I need to remove the untranslated language from being display as per the the theme override. How do I determine the language translations available for nodes with entity translation? Or put another way, how do I determine which language translations are not available for nodes with entity translations?

If you could give me some pointers I would try find a solution.


#22 is a different issue. To alter the behavior of the langauge switcher links you need to implement hook_language_switch_links_alter().