1) enable language support on a node type
2) create in a different language (japanese for example)
3) Override metatag description
4) publish node and view while using default language (English for example
Expected: overridden metatag description used
Actual: default metatag description used.

When viewing the node with the site in the language of the node, the correct metatag is used.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

DamienMcKenna’s picture

So you're saying that the node was created in Japanese, i.e. $node->language = 'jp', and when you view the node in English you don't see the customized meta tags? Isn't that how it should work?

hefox’s picture

Imagine it from perspective of a user -- they are an English speaker entering in Japanese content for their Japanese speakers, so their user language is set to English, but the content they are creating is in Japanese. They go to the meta tag section and override some metatag information and press save. They check the content, making sure it's ready to go, including checking the meta information. However, what they entered is not there, and instead whatever the default settings is. When they were entering content, they had no setting for entering metadata for different languages, just for that single piece of Japanese content, e.g. that content has a single setting and it's not using that setting.

May not be a functional bug, but seems def a UX or such; looking at the code, I didn't see any fault there. Logically, everything made sense, but the result is confusing for the user.

Blackice2999’s picture

Hi,

a other example for this bug is. If you have untranslatable content types they are always with the default language as language set. So nodes that you can see on different language pages the metatag is only be vissible under one language. For "robot" metatags this is a unwanted behavior.

If i understand the concept currently right the metatag module select the right metatag settings with hook_entity_view by building a cache key based upon the entity language. But exactly this is the problem... the node is in englisch and the currently language is a other language (for example DE) so the cache must be misses because the language identifer is part of the cache key.

    // The requested language is different to the entity's language, look for
    // a language elsewhere.
    if ($entity_language != $langcode) {
      // No language was defined for the entity.
      if ($entity_language == LANGUAGE_NONE) {
        $langcode = LANGUAGE_NONE;
      }
      else {
        $enabled_languages = field_content_languages();
        foreach (field_language($entity_type, $entity) as $field => $lang) {
          // Only accept actual language values that are properly enabled.
          if ($lang != LANGUAGE_NONE && in_array($lang, $enabled_languages)) {
            $langcode = $lang;
          }
        }
      }
    }

    // All applicable pieces for this current page.
    $cid_parts = array(
      'entity_type' => $entity_type,
      'bundle' => $bundle,
      'entity_id' => $entity_id,
      'revision_id' => $revision_id,
      'langcode' => $langcode,
      'view_mode' => $view_mode,
    );
    $cid = metatag_cache_default_cid_parts($cid_parts);

    if ($cache = metatag_cache_get($cid)) {
      $output = $cache->data;
    }

Possible Idea for a solution:

This will be no fast and workaround but i think this is neccesary for the future. Use a field that stores the cache idenfier on entity save. So if you save the entity the field value is by default in LANGUAGE_NONE ... now we can use entity_translation to store a cache identifer per language... this can be done on top of current metatag implementation and could be a extra module "metatag_field"

What do you think about it?

DamienMcKenna’s picture

DamienMcKenna’s picture

DamienMcKenna’s picture

Status: Active » Postponed (maintainer needs more info)
hefox’s picture

I don't think so; I believe we were using that patch and the issue remained (not a developer on the project that is experiencing this anymore)

DamienMcKenna’s picture

This should be fixed in the latest -dev release, which will be the 1.0-rc1 release soon. If the problem persist feel free to reopen it and provide further details.

DamienMcKenna’s picture

Status: Postponed (maintainer needs more info) » Active
Parent issue: #2175021: META: Plan for Metatag 7.x-1.0-rc1 release »

Ok, I was contacted by someone experiencing this and have confirmed the problem.

DamienMcKenna’s picture

Going to fix this for the next release.

Now that we have a settings page I'm thinking of making this customizable, i.e. provide an option to control whether the entity's default language should be used if present if there is nothing currently available for the current language. I might even default the option to "on". What do you think, hefox?

DamienMcKenna’s picture

Status: Active » Needs review
FileSize
3.85 KB

This adds a new option on the Advanced Settings page which makes Metatag use the entity's default language's values if none were found for the current language.

DamienMcKenna’s picture

FYI the above reworks the language handling a little so needs further testing.

hefox’s picture

Not active in a project that is using metatags and languages at the moment, but seems good from a brief looksee

DamienMcKenna’s picture

FileSize
4.62 KB

Added a note to the README.txt about the new option.

DamienMcKenna’s picture

FileSize
4.58 KB

This simplifies the logic when deciding what language to use:

  • First off, if no $langcode is passed to metatag_generate_entity_metatags() it uses $GLOBALS['language_content']->language, i.e. the language of the current page request.
  • If the entity has no languages defined, i.e. entity_language() returns LANGUAGE_NONE, then use LANGUAGE_NONE.
  • If the entity has no meta tag values defined for the current language, but there are values for the entity's default language and the new "Load entity default language values if none match" option is enabled, use the entity's default language.
  • Otherwise, use the langcode passed into the function.

Because we're now loading all of the meta tags for all languages during entity_load() I think it's safe to do this.

DamienMcKenna’s picture

Status: Needs review » Fixed

Committed. Hopefully this will help.

  • DamienMcKenna committed 54b4459 on 7.x-1.x
    Issue #2185791 by DamienMcKenna: Improved logic for deciding which meta...
DamienMcKenna’s picture

Status: Fixed » Needs work

After thinking on it further, I'm going to change the default to the reverse of the current situation - automatically load the meta tags, with an option to disable it.

DamienMcKenna’s picture

FileSize
4.35 KB

This patch reverses the logic so that values saved for the the entity's default language will be used should there not be any assigned for the current language.

DamienMcKenna’s picture

Status: Needs work » Needs review
DamienMcKenna’s picture

Status: Needs review » Fixed

Committed.

  • DamienMcKenna committed bd601eb on 7.x-1.x
    Issue #2185791 by DamienMcKenna: Changed the no-values-to-load entity...

  • DamienMcKenna committed 0c54bf7 on 7.x-1.x
    Issue #2185791 by DamienMcKenna: Changed the no-values-to-load entity...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

mfb’s picture

Is there a way to set this option per-metatag?

For example, I always want to use a language-specific metatag for the canonical URL - if the canonical URL defaulted to that of the default language, then, for example the French version of a page would have its canonical URL set to that of its English version, instructing search engines not to index the French page.

However, for other metatags, like an image, I always want the non-English versions to use the metatag defined on the English version if a language-specific metatag wasn't defined.