Hello,

I am working on a highly bilingual and "symmetric" website where 90% of contents is translated.

The language switcher was set as to change both the interface AND lead to the translated node/view (on a language path detection mode).

Activating the Entity translation module changes the behaviour of the Language switcher -- which is still ok for changing the interface, but NOT the node or view.

I tried all available detection options to no avail. Take note that the only translatable field type selected was "user".

+++

I would like to use Entity translation to translate some user-specific fields such as Organization name, Organization description -- Obvioulsy I would have used the Content Profile module back in the D6 days...but the Entity approach looks promising. I hope I could make it work while keeping the node-based translation for the rest of the website.

Thank you

Files: 
CommentFileSizeAuthor
#13 1147046-entity-switcher.patch951 bytesnetsensei

Comments

Status:Active» Fixed

After enabling ET you should find another language switcher block that switches content.

Status:Fixed» Active

I "should" but I don't see any new language switcher in my available block options.

Do I have to activate the ET translation upgrade module? Actually, I don't want to change the node-based i18n behaviour of the website, except for one "Users" section where I need to translate two specific fields.

Category:support» bug
Priority:Normal» Minor

Ok I see.

Under the "Translatable entity types", all options must be selected for the Content language switcher block to appear.

Selecting only the "user" option doesn't provide it. So I guess this is more like a minor bug.

However my main problem is now solved. Thanks.

Title:Behaviour of language switcherLanguage switcher do not link to translated node when entity translation is installed

Hello,

I found some details on this issue.

entity_translation sets variable translation_language_type to LANGUAGE_TYPE_CONTENT in entity_translation.install:

<?php
  variable_set
('translation_language_type', LANGUAGE_TYPE_CONTENT);
?>

I don't know if and why this is needed but, the point is that the code in translation.module that changes the node for the translated node in the target language will only work with a 'translation_language_type' value of LANGUAGE_TYPE_INTERFACE.

<?php
function translation_language_switch_links_alter(array &$links, $type, $path) {
 
$language_type = variable_get('translation_language_type', LANGUAGE_TYPE_INTERFACE);
  if (
$type == $language_type && preg_match("!^node/(\d+)(/.+|)!", $path, $matches) && ($node = node_load((int) $matches[1]))) {
?>

Even if entity translation is unactivated, the variable remains and the language switcher stays broken.

If ET is not used, it can be uninstalled. The variable is deleted and the language switcher is restored.

Status:Active» Closed (works as designed)

The behavior you are describing is exactly how everything is supposed to work: ET enables the content language type to be configured, this makes the content language switcher block available. The core content translation module is supposed to deal (and affect) content so, as the names suggest, the interface language switcher will switch only the UI language, while the content language switcher will switch content language, i.e. nodes, in the case of node-based translation. To obtain the usual behavior in which content and UI language are tied and switched together, you just need to enable, for instance, URL language detection for both language types and use the content language switcher block instead of the interface one.

I tried ET, then unactivated it. I didn't notice immediately that the language switcher was not functioning as usual. Then lost too much time to figure it out. Shouldn't the 'translation_language_type' variable be restored to its default value (or deleted) when ET is unactivated to restore the previous behavior ?

@pyhair:

Shouldn't the 'translation_language_type' variable be restored to its default value (or deleted) when ET is unactivated to restore the previous behavior ?

Yes, see line 102:

http://drupalcode.org/project/entity_translation.git/blob/aaafd2a1543823...

Assigned:Unassigned» StryKaizer

I'll create a patch for this asap.

nvm, this behavior is fixxed in 7.x-1.0-alpha1 already.

Status:Closed (works as designed)» Needs work

Seems to me that this problem still persists. Merely deactivating ET does not flip the 'translation_language_type' back to its original value. The patch above only works when you actually uninstall ET alltogether.

I see several issues with this:

1. It's easy to forget to uninstall the module after disabling it. A good dev will always uninstall a module through the interface before removing the module code. Moreover, ET changes a global setting which is used/set by core. And core does not provide a way to change it if you've removed ET.
2. During development/testing, a dev might disable the module - perhaps temporarily - for any development reason rather then disabling it: he might want to keep the ET settings in the DB if he enables the module later on. But in the meanwhile: the switcher is borked.
3. It's unclear that disabling the module breaks the language switcher. It's easy to overlook that something goes wrong unless you do thorough tests after each change you make. You'll lose boatloads of time if you pick up on the problem days later.

To me, variable_del('translation_language_type'); needs to be moved to the hook_disable implementation rather then in hook_uninstall

Status:Needs work» Closed (works as designed)

To me, variable_del('translation_language_type'); needs to be moved to the hook_disable implementation rather then in hook_uninstall

Makes sense, this might be left out from #1280660: Gracefully handle module being disabled and re-enabled. Patches welcome.

Status:Closed (works as designed)» Needs work

StatusFileSize
new951 bytes

Patch attached. I'm not too sure about variable_del('locale_field_language_fallback'); either. That's also a variable managed by the locale module.

@netsensei:

I'm not too sure about variable_del('locale_field_language_fallback'); either.

Yes, it should be handled too. In the issue above we backup settings on disabling and restore them on enabling the module. We should handle 'locale_field_language_fallback' and 'translation_language_type' the same way as "language_content_type_$type" variables.

Seems to me that for over a year now this issue has existed and it cost me almost a day of headache trying to figure out why my language switcher was broken all of a sudden.

comments #3 and #5 fixed it for me. With extra special emphasys on

you just need to enable, for instance, URL language detection for both language types and use the content language switcher block instead of the interface one.

This is exactly the kind of motivating post that makes doing volunteer coding a joy.

You are absolutely right. And I apologise. I absolutely appreciate all the coding that you guys are doing voluntarily. But that doesn't mean that Drupal can sometimes give me a meltdown :) Sometimes it is very hard to figure out. Got it working atm and will edit my post to add my solution.

I know, I know, meltdowns happen all the time, rants way too often ;)

Anyway the problem here is that none bothered to address my feedback in #14: the current solution is incomplete and as such cannot be committed. I'm pretty sure you can solve your issues by: either uninstalling ET or, if you wish ET and node translation to coexist, to enable the content language switcher block instead of the interface language one.

Title:Language switcher do not link to translated node when entity translation is installedDisable node translation language switcher integration when disabling ET