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

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

plach’s picture

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).

torpy’s picture

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).

heretic381’s picture

Status: Needs work » Needs review

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

torpy’s picture

Minor fix, one of the conditions was too ambiguous.

nikosnikos’s picture

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

heretic381’s picture

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.

heretic381’s picture

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).

Erik.Johansson’s picture

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.

heretic381’s picture

Hi,
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.

Cheers.

heretic381’s picture

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.

heretic381’s picture

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.

bforchhammer’s picture

Status: Needs review » Needs work

NW based on previous comments.

Mohammed J. Razem’s picture

Status: Needs work » Needs review
FileSize
3.45 KB

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.

plach’s picture

heretic381’s picture

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.

plach’s picture

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

heretic381’s picture

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

plach’s picture

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.

heretic381’s picture

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.

Nicolas Bouteille’s picture

Hi,

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.

Nicolas Bouteille’s picture

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).

guysaban’s picture

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

heretic381’s picture

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.

plach’s picture

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.

heretic381’s picture

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

plach’s picture

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.

heretic381’s picture

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?

plach’s picture

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.

guysaban’s picture

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?

guysaban’s picture

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

plach’s picture

@guysaban:

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

valderama’s picture

Issue summary: View changes

Regarding the language switcher (guysaban in #22 and plach in #31) - I have posted a snippet, that makes the language switcher only display links to existing translations.

It is available here:
http://dropbucket.org/node/1570

josebc’s picture

patch based on #13 with fix for warning and including all entity types

josebc’s picture

Status: Needs work » Needs review
josebc’s picture

re-roll with after adding the missing helper function

josebc’s picture

Ahmad Abbad’s picture

#36 patch work fine, with problem in field image (default image) not show in Arabic language for anonymous users .

Mentor.37’s picture

Unfortunately the patch does not work with the current dev version.

titouille’s picture

Hi, #35 tested and a little problem with the conditions alias process.

In my case, on the standard homepage, the query conditions array contains a condition like this :

array(
  'field' => '',
  'value' => (object) SelectQuery,
  'operator' => 'EXISTS',
);

This condition is added like this :

AND ( EXISTS (SELECT ... ) )

Problem is that your code replace the standard condition by the following :

AND ( n. EXISTS (SELECT ... ) )

And break the query.

Adding a test like !empty($condition['field']) resolve the problem :

if(is_array($condition) && isset($condition['field']) && is_string($condition['field']) && !empty($condition['field'])) {

instead of
if(is_array($condition) && isset($condition['field']) && is_string($condition['field'])) {

Hope this help.

titouille’s picture

grahl’s picture

We're having an issue with the patch in #40 in combination with search_api_et (7.x-2.x-dev). Without the patch the item is correctly added to the tracked items, with it search_api_track_item_insert() does not track the entity.

We are specifically seeing this with a node created with a language (de) other than the default language (en).

Any tips on how to avoid this would be appreciated, we currently don't see an easy solution without an ugly patch to search_api.

grahl’s picture

OK, I looked a bit more into the patch and I actually don't understand what the query is doing with the language condition.

The condition array($GLOBALS['language_content']->language, LANGUAGE_NONE) should always give back the default field language and UND, which is...limiting. I removed the condition and rerolled the patch but I don't really grasp the condition I forced there.

Nonetheless I seem to not have the fallback notice and my nodes are indexed.

svax’s picture

I think this issue is about what nodes are listed in the default drupal listings, not about the message of unavailable translations. As mentioned in comment #28, I created a separate issue for adding the setting to hide message: #2693629: Add a setting for hiding the unavailable translations message

If that patch is committed, this patch should be re-implemented without the setting.