[term:i18n-vocabulary:name] token doesn't seem to be working

[herbdool]

The [term:i18n-vocabulary:name] token isn't working. In hook_tokens() the $token array has i18n-vocabulary:name as a key but i18n_taxonomy_tokens() expects i18n-vocabulary on line 83.

If I change it to expect i18n-vocabulary:name it works.

I'm not sure if this is a result of any changes to token processing. It might have something to do with entity_tokens module but even after I disable it, it still doesn't work

[herbdool]

I realized that [term:i18n-vocabulary] token does work and that's what i18n expects. But it can't deal with the child tokens. For my case I only need the main one.

[argiepiano]

Hi @herbdool. A few quick comments about these tokens. So, i18n-taxonomy declares the token i18n-vocabulary as being a token of type vocabulary. This is the reason why the token tree shows the option to chain it with all vocabulary type subtokens, including name, machine-name and other vocabulary subtokens.

The problem is that chaining fulfillment for i18n-vocabulary is never implemented by i18_taxonomy.tokens.inc. To implement chaining fulfillment you would have to add code after the switch sequence that looked like:

    // Chained token relationships.
    if ($vocabulary_tokens = token_find_with_prefix($tokens, 'i18n-vocabulary')) {
      $vocabulary = taxonomy_vocabulary_load($term->vocabulary);
      $replacements += token_generate('vocabulary', $vocabulary_tokens, array('vocabulary' => $vocabulary), $options);
    }

The above would take care of fulfillment of all subtokens chained after i18n-vocabulary. This should be added to this module.

A couple of related comments

• Typically when you fulfill tokens you don't want to explicitly check for chained ones like i18n-vocabulary:name. Instead, typically, the switch will check for single tokens (un-chained) and then, after all have failed, you would use token_find_with_prefix to fulfill chained ones.
• And second: moduleentity_token has absolutely no effect here, since it only cares about tokens derived from entities (e.g. entity properties or fields), and uses entity_metadata_wrapper to fulfill those. i18n-vocabulary is not an entity. And while taxonomy terms are entities, i18n-vocabulary is not a known property of terms.

[indigoxela]

... i18n-vocabulary is not an entity

@argiepiano right, many thanks for clarifying.

[herbdool]

@indigoxela I added a PR based on @argiepiano's suggestion. It's for i18n-vocabulary and i18n-parent.

[indigoxela]

@herbdool great, many thanks for providing the PR. Will try to test ASAP. :+1:

[indigoxela]

@herbdool what's the best way to test this? I'm struggling to find a valid test case for these tokens.

[herbdool]

You can put the vocabulary and parent term in a url alias pattern, along with the term. And then localize them. And make a term a parent of another term.

[indigoxela]

Huff, I forgot what a nightmare this user interface is. :disappointed:

• A taxonomy vocabulary
• Set it to "Localize"
• Localize the vocab?
• Adapt the url alias pattern to something
• Add parent term
• Add child term
• Localize...

And lost again...

I know, I'm sort of maintainer of i18n, but this part (term translation) is just so awkward, that I need a step-by-step instruction. Ideally in a way that afterwards I can write an automated test for that.

[herbdool]

Yes, it is confusing.

And yes, I've tested with the "Localize" option too provided by

I had a site that had this [term:i18n-vocabulary:name]/[term:i18n-name] on their Drupal 7 site and the vocab wasn't working so that's why went down this rabbit hole. In this case [term:i18n-vocabulary] is good enough but thought I'd provide a PR to allow other sub-tokens be used. And I tested this too [term:i18n-vocabulary:name]/[term:i18n-parent:name]/[term:i18n-name].

I think you have to localize the vocabulary first, then add term and save. Then localize that term and add a child term.

The funny thing which I hadn't thought about before now is that the URL will only use the localized term of the interface. So if I switch to French it'll use the French name. And if I switch to English it'll use the English name for the URL. So maybe this isn't what I was looking for, but still useful to see if the PR is working.

So I've tested the option available without this PR: [term:i18n-vocabulary]/[term:i18n-parent]/[term:i18n-name] and this works. But testing this again now, [term:i18n-vocabulary:name]/[term:i18n-parent:name]/[term:i18n-name] does not work fully yet. It fills in the vocab name and parent name but doesn't localize it.

[herbdool]

Oh, actually it does work but need to use [term:i18n-vocabulary:i18n-name]/[term:i18n-parent:i18n-name]/[term:i18n-name]. I guess the i18n-name makes the sense.

[indigoxela]

Oh, right, the current interface language might have tricked me... I'll give testing another stab.

[indigoxela]

Update: right, the interface language tricked me when testing, and I also struggled with the "name" vs. "i18n-name" topic.

It's a bit odd that - with localized terms - the url will switch whenever the term gets saved (again) on another interface language. Confusing behavior, but probably it "works as designed".

I can confirm that the PR fixes the token handling, as without the patch applied, the vocab and parent tokens stay empty.

[indigoxela]

@herbdool thanks, merged. :+1: