What I'm trying to do is generate a path in Pathauto using the hierarchy of a taxonomy term. Essentially, if my content belongs to Term 1 > Term 2 > Term 3, then my path should be term-1/term-2/term-3/content. I'm using the title module to replace the name field.

This works fine, when editing content in the same language as the page. What doesn't seem to work is editing content in a different language. For example, if (using Entity Translation), I attempt to translate the English content using the French backend (or vice versa), I get the wrong parent terms (but the right term and content). Trying to import content using Migrate in both languages at once has the same problem.

I tracked this down to the function token_taxonomy_term_load_all_parents($tid). When taxonomy_get_parents_all($tid) is called, it loads the parents in the current language and nothing is being done to translate the labels of those terms.

The ideal solution (I think) is that this should be entity_label('taxonomy_term', $term, $langcode); and $langcode should come from $options['language'] from the tokens_tokens() call. This runs into the problem of #1775768: Backport langcode support for all entity labels though, which prevents title_entity_label() from using the $langcode parameter and probably doesn't let i18n_taxonomy play with it either. Alternatively, we could hack it for now (either reimplement entity_label with a $langcode parameter OR detect if title replacement is enabled and call the callback directly (as well as some solution for using i18n_taxonomy's method to fix the string as well)).

I kindof need this, so I'm willing to put in some work and submit patches where needed, I'm just not really sure on which direction to take to get this ironed out for now.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ottawadeveloper’s picture

Assigned: Unassigned » ottawadeveloper
Status: Active » Needs review
FileSize
3.09 KB

So here's a first effort at some kind of a fix for anyone who wants a quick patch to fix this issue.

Here's a summary of the changes:

  • token_taxonomy_term_load_all_parents() now has a second, optional parameter for $langcode. The default is NULL which should continue to provide the same behaviour for calls that don't want to specify the language.
  • That function now first localizes the terms using i18n_taxonomy if available and then gets the label in a way that supports a langcode parameter. For both of these, a new function was introduced which simulates the behaviour of the original function (i18n_taxonomy_localize_terms and entity_label) but with a $langcode parameter.
  • The resulting labels are also now statically cached by language, to avoid any conflicts should two languages be requested on the same page.
  • Calls to token_taxonomy_term_load_all_parents() in token.tokens.inc now pass the $language_code variable (which comes from $options['language'] and is used elsewhere to determine the language).

Status: Needs review » Needs work

The last submitted patch, title-module-friendly-terms-2033419-1.patch, failed testing.

ottawadeveloper’s picture

Status: Needs work » Needs review
FileSize
4.67 KB

This is what I get for working on multiple projects at once...

Status: Needs review » Needs work

The last submitted patch, title-module-friendly-terms-2033419-2.patch, failed testing.