pathauto patch to provide localized and entity translated taxonomy through i18n

This does seem like a feature request to me. I've re-stated it. Since I don't use i18n I won't be able to develop this patch but if it is minimally invasive on Pathauto then it seems reasonable to me to commit it.

A patch would be much appreciated.

Subscribing, it strange to see multilanguage feature for nodes and not for taxonomy...

subscribe

subscribe

would be great to find a solution for that.

If this is for the i18n module ( http://drupal.org/project/i18n ) then it should really be about adding tokens to that module to support the localized terms.

Subscribing

It is not an i18n issue, it is a pathauto issue to work with localized terms...

localized terms

But which module provides localized terms?

Here is a patch that allows you to set per-language patterns for taxonomy, in the same way you can for content types. It's pretty straightforward, and I think should apply to both the 1.x and 2.x branches for Drupal 6. As you will see, this is much easier to implement in pathauto - implementing within i18n taxonomy would involve a large amount of code duplication.

Note - this works for "fully translated" vocabularies (which is the recommended approach) - i.e. I18N_TAXONOMY_TRANSLATE. Vocabularies per-language (i.e. I18N_TAXONOMY_LANGUAGE) should already work without this patch. This patch won't do anything for "Localized" vocabularies (i.e. I18N_TAXONOMY_LOCALIZE), but that is a pretty limited approach to start with and I am not sure is really supportable in pathauto.

Owen - that's a very interesting idea, but feels like a heavy solution to me and I don't like the idea that Pathauto is dependent on a seldomly used contributed module. Is it not possible to provide new tokens from the i18n_taxonomy module that would "do the right thing" ?

@greggles - pathauto is not dependent on i18n with this patch - if it is not installed it should work exactly as before. Also i18n module is not exactly seldom used - it is in the top 50 most popular projects, (more popular then path redirect, logintoboggan and ubercart, for example) - it is basically required if you want to build any (non-trivial) multilingual site.

I don't think i18n module providing tokens is a good solution - this might work if you only ever use the vocabulary name itself and catpath as the alias (and so could use a translated vocabulary name token) - but if you need to prefix the aliases with text to place them in some site section (as is the case most of the time in my experience) you need an interface to set this text prefix. This means admins would need to go to some i18n admin page to add and configure special tokens to translatable "vocabulary paths" (basically just tokens that convert to short translatable plain text strings), and then go to locale module and translate those strings, and then go to the pathauto page and add the tokens they previously configured.

This approach would extremely complex from an admin point of view and fragile from a technical point of view, in addition these tokens would be specific to aliases, so would not be useful for anything else. I think it is better for pathauto to provide a consistent interface - it already handles the language perfectly in the backend, we just need to change 2 lines of code so the term language is actually loaded and passed to pathauto_create_alias().

I was a bit confused - I thought "i18n taxonomy" was separate from the main i18n module. I see now that it is a sub-module which makes it hard to know whether it truly is in the top 50 or not.

The fact that node translations are in core and taxonomy not puts us in a tricky position. I'll wait for Freso to weigh in on this because I am hesitant to add it, but don't do much work with i18n so better for a more knowledgable person to provide feedback.

One problem we had with the i18n node code is that there are a few bugs with it. I would be happier to accept this if you could also provide some simpletests to help us know that we don't break it in the future.

And thanks again for your hard work providing the patch and (maybe harder) explaining it to me ;)

Here's a version of Owen's patch in #11 that works with localized vocabularies. Use with caution as I haven't tested it very thoroughly and it fudges the language property of each term object (which are language independent in localized vocabularies) to get around the lack of i18n support in the token module.

Patterns can be specified per language - use the [i18n-cat] and [i18n-cat-raw] tokens to get the translated term name provided by i18ntaxonomy.

Sub

+1

I would be happier to accept this if you could also provide some simpletests to help us know that we don't break it in the future.

+1 is not helpful.

Sub

sub

subscribe

subs are not helpfull too
will test this tomorrow evening

I just applied the patch and it works great!

Subscribe!

subscribing

@DomoSapiens #290421-23: pathauto patch to provide localized and entity translated taxonomy through i18n
Can you please (next time) specified WHICH ONE? Thnx ;)

@all
In this issue #431746: original node path replaced after translating node, both have same path not translated terms
is no problem with translations of [termpath-raw]/[title-raw]!?!
What I missed, please?? (It is after this patch or what?)

(I have same problem like its subscribed here: hierarchy vocab, localized terms,.. but no translation in url alias.)

@Mattez

Sorry about that! I use the patch of #15
http://drupal.org/node/290421#comment-1767818

Subscribing!

Please fix this in pathauto code :s

EDIT:

I'm missing :

For taxonomy
[i18n-catpath-raw]
[i18n-vocab-raw]
[i18n-catpath]
[i18n-vocab]
For nodes
[i18n-termpath]
[i18n-termpath-raw]

To add i18n-catpath & i18n-catpath-raw change this inside pathauto_token_values (pathauto.module):

          if (isset($category->tid)) {
            $separator = variable_get('pathauto_separator', '-');
            $parents = taxonomy_get_parents_all($category->tid);
            array_shift($parents);
            $catpath = '';
            $catpath_raw = '';
//CHANGE HERE
            $catpath_i18n = '';
            $catpath_i18n_raw = '';
//\CHANGE HERE
            foreach ($parents as $parent) {
              // Replace any / characters in individual terms which might create confusing URLs
              $catpath = pathauto_cleanstring(check_plain(preg_replace('/\//', '', $parent->name))) .'/'. $catpath;
              $catpath_raw = pathauto_cleanstring(preg_replace('/\//', '', $parent->name)) .'/'. $catpath_raw;
//CHANGE HERE
              $catpath_i18n = pathauto_cleanstring(check_plain(preg_replace('/\//', '', tt("taxonomy:term:$parent->tid:name", $parent->name, $category->language)))) .'/'. $catpath_i18n;
			  $catpath_i18n_raw = pathauto_cleanstring(preg_replace('/\//', '', tt("taxonomy:term:$parent->tid:name", $parent->name, $category->language))) .'/'. $catpath_i18n_raw;
//\CHANGE HERE
            }
            $values[$label .'path'] = $catpath .'/'. check_plain($category->name);
            $values[$label .'path-raw'] = $catpath_raw .'/'. $category->name;
            $values[$label .'alias'] = drupal_get_path_alias('taxonomy/term/'. $category->tid);
            if (!strncasecmp($values[$label .'alias'], 'taxonomy', 8)) {
              $values[$label .'alias'] = check_plain($category->name);
            }
            $values['i18n-cat'] = check_plain(tt("taxonomy:term:$category->tid:name", $category->name, $category->language));
            $values['i18n-cat-raw'] = tt("taxonomy:term:$category->tid:name", $category->name, $category->language);
//CHANGE HERE
            $values['i18n-catpath'] = $catpath_i18n .'/'. check_plain(tt("taxonomy:term:$category->tid:name", $category->name, $category->language));
            $values['i18n-catpath-raw'] = $catpath_i18n_raw .'/'. tt("taxonomy:term:$category->tid:name", $category->name, $category->language);
//\CHANGE HERE		
          }

----------------------------
JGO | http://www.e2s.be
----------------------------

Thanks for your feature request and for helping make this a better module. Could you provide this as a patch?

Sorry, don't have cvs etc installed ...

+1

These seem to be quite different patches. Can anyone explain which one (or both) is the "right" one?

Another bug I discovered was that when changing the translation of a term, the alias was not updated (only for the untranslated original)
So this is missing as well (Needed to do bulk update to get new alias)

I must say that I use pathauto 6.x - 1.2 with the patches from this thread

----------------------------
JGO | http://www.e2s.be
----------------------------

bump :)

Subscribing

I've rolled up together patches from #15 and #31, trimmed the extra whitespace and ported to latest 6.x-1.x-dev. I've also added missing strings in the token list.

Like others on this thread so far, I've just had minimal time to test, but it does look like translated aliases (including i18n-catpath) are correctly generated.

So if like me, you want to move this forward, please download 6.x-1.x-dev, apply this patch and report any further observations!

EDIT: As JGO mentionned in #34, changing the translation of the term doesn't update the i18n URL alias.

Sorry for butting in people, but I need to ask this...

Is this feature request for making it possible to have paths that include term names translated in the currently selected language?

I mean does it intent to make it possible so that we have available paths like so (using [termpath-raw]/[title-raw]):

en/big-blue-dog/jack
fr/grand-bleu-cabot/jack
it/grande-blu-cane/jack

Did I get this right or am I missing something?

This is right indeed!

Then please have a look at this issue: #736178: Add a [node:source] token for source node of a translated node

So, when you fix this one, do take under consideration what this means to people with non-US-ASCII locales. My guess is that your feature will need some kind of polite fallback. Either that or it needs to be optional by say using a different replacement patterns than [termpath-raw].

@JGO: What you propose in #27 for tokens like [i18n-termpath] & [i18n-termpath-raw] seems ok. Generally, prefixing tokens that are meant to be the localized versions of their respective non-localized ones with 'i18n-' is good thinking.

I know this might be on your mind(s) already, so this is just a reminder. Thank you.

@klonos: From what I understand of working with this patch, it doesn't change the behavior of existing tokens. The extra i18n functionaly is only enabled using [i18n-*] tokens.

I was pretty sure it did exactly that. I just needed to make sure.

I also wanted let people know of the issue I am talking about when it comes to putting non-US-ASCII locales in the URL. That brings ugliness when it comes to IE + such URLs and also produces URLs that don't make sense. So, I was thinking about having some short of fallback. Let me explain that last one...

Think of this use case of a multilanguage site where you have both locales with what I call latin-like alphabets and other locales that don't use such alphabets. The first category includes locales with letters like è, é, ê, or ë and à, á, â, ã or ä and ò, ó, ô, õ or ö that are easily transliterated to e, a and o respectively. No problem there, you can have the i18n taxonomy paths transliterated and all is fine (well... 99% of the times). The second category I speak of includes Arabic and Asian languages as well as Hebrew and Greek (these come to mind, there might be others though). Transliteration doesn't help at all in those.

It is ok if a multilanguage site uses languages only from the first category or only from the second. The first will use the product of this issue (be it a patch or code included in future versions of the module eventually) and perhaps Transliteration in order to sort things out, whereas the second would not use it at all and that's it.

In the case of a multilanguage site that uses a mixture of languages from both categories I speak of, you would want to use the support of localized taxonomy for the locales that have latin-like alphabets, but not for the rest of them. That's where the fallback I mention should come in.

Right now we only have tokens that don't use i18n at all. Soon we will have tokens that use the fallback I mention using [node:source] in D7 and [source-nid] and [source-title] for D6. We will also have i18n-aware ones once this issue is fixed. What will eventually be needed is a combination of these. That is:

[i18n-node:source]
[i18n-source-nid]
[i18n-source-title]

This whole mess can be avoided if you incorporate the fallback by default in this issues fix.

PS: I am aware that the [node:source] refers to nodes and not taxonomy terms or vocabularies, but I am pretty sure there is a 'tid' (or something like that) field somewhere in the db to identify terms and 'vid' to do the same for vocabularies. So, you get my point.

There is also a problem of duplicated content with at least i18n-catpath and i18n-catpath-raw:

You have these URL's:

en/big-blue-dog/jack
fr/grand-bleu-cabot/jack
it/grande-blu-cane/jack

But

fr/big-blue-dog/jack
it/big-blue-dog/jack

Will also work. This is because the EN version is created as language neutral instead of just the language itself (en)

This might be desired behavior to some people. I think (?)

I am not sure what you need to achieve in the example above. Are you trying to have the first set of the three links only without the other two? This must be for SEO reasons, right? Other than that, I see no harm if all exist and point to the same node in the correct language.

I mean the 'jack' part of the URL refers to a node, say a page. That cannot possibly be neutral if it is set correctly ('Require language (Do not allow Language Neutral)' setting in the content type Multilanguage options).

The 'big-blue-dog' part are the taxonomy terms assigned to the node 'jack'. They can be translated or not, but they are supposed to be translatable, right? I mean did you set the vocabulary Translation mode to 'Localize terms. Terms are common for all languages, but their name and description may be localized.' or what?

@klonos: The issues you raised are interesting, but I think are beyond the scope of what this particular modification is trying to achieve. Using a localized version of some tokens may be something relatively new, but don't forget that the same problem applies with node paths, when the title tokens are used in the context of node translations, for example. So the issue of non-ASCII characters in path aliases is not restricted to taxonomies.

Furthermore, while it's true that legacy browsers may have problems with non-ASCII URLs, I think it's safe to say that the global web community and the tools used to access it are gradually moving towards full support for internationalization. Recently, ICANN's much-publicised decision of supporting Internationalised Domain Names (IDN) is, to me, a clear indication of this trend.

Lastly, I think it's safe to say that web users to whom internationalisation support matters will be very quick to adopt friendlier browsers and tools as internationalised URLs become more and more common on the web.

I have an error whne applying the patch #38 on the last 6.x-1.x-dev version.

the code in pathauto.module has change:

***************
*** 123,131 ****
              array_shift($parents);
              $catpath = '';
              $catpath_raw = '';
              foreach ($parents as $parent) {
                $catpath = pathauto_cleanstring(check_plain($parent->name)) .'/'. $catpath;
                $catpath_raw = pathauto_cleanstring($parent->name) .'/'. $catpath_raw;
              }
              $values[$label .'path'] = $catpath . pathauto_cleanstring(check_plain($category->name));
              $values[$label .'path-raw'] = $catpath_raw . pathauto_cleanstring($category->name);
--- 123,135 ----
              array_shift($parents);
              $catpath = '';
              $catpath_raw = '';
+             $catpath_i18n = '';
+             $catpath_i18n_raw = '';
              foreach ($parents as $parent) {
                $catpath = pathauto_cleanstring(check_plain($parent->name)) .'/'. $catpath;
                $catpath_raw = pathauto_cleanstring($parent->name) .'/'. $catpath_raw;
+               $catpath_i18n = pathauto_cleanstring(check_plain(preg_replace('/\//', '', tt("taxonomy:term:$parent->tid:name", $parent->name, $category->language)))) .'/'. $catpath_i18n;
+               $catpath_i18n_raw = pathauto_cleanstring(preg_replace('/\//', '', tt("taxonomy:term:$parent->tid:name", $parent->name, $category->language))) .'/'. $catpath_i18n_raw;
              }
              $values[$label .'path'] = $catpath . pathauto_cleanstring(check_plain($category->name));
              $values[$label .'path-raw'] = $catpath_raw . pathauto_cleanstring($category->name);
***************
*** 135,140 ****
              if (!strncasecmp($values[$label .'alias'], 'taxonomy', 8)) {
                $values[$label .'alias'] = check_plain($category->name);
              }
            }
            else { // Provide some defaults if they aren't set.
              $values[$label .'path'] = '';
--- 139,148 ----
              if (!strncasecmp($values[$label .'alias'], 'taxonomy', 8)) {
                $values[$label .'alias'] = check_plain($category->name);
              }
+             $values['i18n-cat'] = check_plain(tt("taxonomy:term:$category->tid:name", $category->name, $category->language));
+             $values['i18n-cat-raw'] = tt("taxonomy:term:$category->tid:name", $category->name, $category->language);
+             $values['i18n-catpath'] = $catpath_i18n .'/'. check_plain(tt("taxonomy:term:$category->tid:name", $category->name, $category->language));
+             $values['i18n-catpath-raw'] = $catpath_i18n_raw .'/'. tt("taxonomy:term:$category->tid:name", $category->name, $category->language);
            }
            else { // Provide some defaults if they aren't set.
              $values[$label .'path'] = '';

$catpath_i18n and $catpath_i18n_raw are not array not string.

Change to this

$catpath = $catpath_raw = $catpath_i18n = $catpath_i18n_raw = array();
foreach ($parents as $parent) {
  array_unshift($catpath, pathauto_cleanstring(check_plain($parent->name)));
  array_unshift($catpath_raw, pathauto_cleanstring($parent->name));
  array_unshift($catpath_i18n, pathauto_cleanstring(check_plain(preg_replace('/\//', '', tt("taxonomy:term:$parent->tid:name", $parent->name, $category->language)))));
  array_unshift($catpath_i18n_raw, pathauto_cleanstring(preg_replace('/\//', '', tt("taxonomy:term:$parent->tid:name", $parent->name, $category->language))));
}

Any one succeded to add [i18n-vocab-raw] and [i18n-vocab] as token ?

Works for me!!!!!

/**
 * Implementation of hook_token_values() for uc_catalog specific tokens.
 */
function uc_catalog_token_values($type, $object = NULL) {
  if (module_exists('taxonomy')) {
    if ($type == 'taxonomy' || $type == 'node' || $type == 'all') {
      _pathauto_include();
      switch ($type) {
        case 'taxonomy':
        default:
          if (!isset($category)) {
            $category = $object;
          }
          if (!isset($label)) {
            $label = 'cat';
          }
          
          if (isset($category->vid)) {
            $separator = variable_get('pathauto_separator', '-');

            $catalog_name = variable_get('uc_catalog_name', 'Catalog');
            $catalog_id = variable_get('uc_catalog_id', '1');

            $values['i18n-vocab'] = check_plain(tt("taxonomy:vocabulary:$catalog_id:name", $catalog_name, $category->language));
            $values['i18n-vocab-raw'] = tt("taxonomy:vocabulary:$catalog_id:name", $catalog_name, $category->language);
          }
          else { // Provide some defaults if they aren't set.
            $values[$label .'path'] = '';
            $values[$label .'path-raw'] = '';
            $values[$label .'alias'] = '';
          }
      }
      return $values;
    }
  }
}

/**
 * Implementation of hook_token_list() for Pathauto specific tokens.
 */
function uc_catalog_token_list($type = 'all') {
  $tokens = array();
  if (module_exists('taxonomy')) {
    if ($type == 'taxonomy' || $type == 'all') {
      $tokens['taxonomy']['i18n-vocab'] = t('Vocabulary name translated using i18n.');
      $tokens['taxonomy']['i18n-vocab-raw'] = t('Unescaped vocabulary name translated using i18n. WARNING - raw user input.');
    }
  }
  return $tokens;
}

Thanks for your comment and for helping make this a better module. Could you provide this as a patch?

Try this, i´m new pathching ... sorry my english is horrible!!!!!!

would be possible to backport the patch to D6?

Sorry I don´t think so, it´s needs work because the patch assumes you´ve installed i18n module ... but i think in a few days i cant improve the patch and delete dependencies.

Well... that could be great. I'm available for patch testing!

The patch #38 no longer works against 6.x-1.x-dev version. And I cannot understand where the code from #48 and #49 goes to.

It would be great to have a 6.x version of this... can anyone help?

EDIT: #51 includes previous patches? And works against 6.x-1.3. Is this correct? But I can see [vocab] and [termpath] for node replacement patterns but no [i18n-vocab] or [i18n-termpath]

Need to add a test to check if i18n is installed before each call of the function tt().
if (module_exists('Internationalization')){

Of course it is installed in the multilang website, but in a drupal multisite environnement all websites are not allways international.

Talking about tt()... it seems to be deprecated and should be replaced by i18nstrings(). Please take a look here: #358839: Fatal error: Call to undefined function tt() (post #3 and later)

When using patch from #51 I have the same bug described in this thread #278368: taxonomy_term_path being passed TID instead of Term Object:

I still have this bug on 6.x-1.3, every time I change name of terms, i get taxonomy/term/id becomes aliased to taxonomy/term

In path auto settings I have:

Update action:
Do nothing. Leave the old alias intact.
Create a new alias. Leave the existing alias functioning.
Create a new alias. Delete the old alias.
X Create a new alias. Redirect from old alias.

Pattern for all language neutral Tags paths:
[i18n-vocab-raw]/[i18n-cat-raw]

I'm also using Path redirect 6.x-1.x-dev (2010-Mar-19) and Internationalization 6.x-1.4

Help is really welcome

Indeed heyyo I saw the same behavior over here which messes up the whole site

Anything new on this ?
It's really critical...

Hi
Try this patch against 6.x-1.4 version.
It works for me.
Have fun.

@pokurek: Petr, is this an improvement over the patch in #51 or a complete new approach to the issue? Your patch introduces a couple of whitespace here and there. Also I think that new features go to dev versions and to latest branches, so it would be great if you did this against 2.x-dev. Thanx in advance.

@lord_of_freaks, #53: well it's been a little more than a few days now Alejandro ;)

There is nothing else then what is in the patch #15 and #51.
I only add:
- new control for i18n module #53,
- i18nstrings() replacement for tt() mentioned in #57,
- [i18n-termpath], [i18n-termpath-raw] node tokens.

Sorry about a couple of whitespace.

I try make patch against 2.x-dev, but it is not so well tested.
I don't run patchauto.test script either.
Just start to work ;o)

Thanx for taking the time to reply and for the updated patch Petr.

Pokurek, thank you very much for the 290421-pathauto-DRUPAL-6--1-4.patch
I really hope it will get into pathauto stable some day :|

Ping?

I have applyed #61 on pathauto 6.1.4. But I have strange behaviors.

I have 2 type of vocabularies:

1) Translation mode:
Per language terms.

2) Translation mode:
Localize terms.
Tags, multiple selected

In my Automated alias settings I have only the following:

TAXONOMY TERM PATHS
Default path pattern (applies to all vocabularies with blank patterns below):
[i18n-catpath-raw] (i also tried [i18n-cat-raw], I have the same bug)

all other fields are empty.

Results :

1) All my terms from 1st vocabulary are correctly aliased with translated terms
2) Terms in french/hebrew in 2nd vocabulary are correctly aliased with translated terms, but all my english terms are not aliased at all. (even if I tried press the button another time)

Does this patch works better with pathauto 6.x-2.0-alpha2 ?

EDIT: I have same behavior with pathauto 6.x-2.0-alpha2

Subscribing

I created patch against 6.x-1.5 version.

#67: Maybe I have found a small bug.
If vocabulary mode is I18N_TAXONOMY_LOCALIZE (Localize terms), like 2) type of vocabulary in your example, than terms aliases are set only for each language, not for "All".
Try if it help you.

Thanks pokurek.

But I still have bug with it. I have a parse error:

user warning: 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 ') LIMIT 0, 50' at line 1 query: SELECT td.*, src, dst FROM term_data td LEFT JOIN url_alias ON CONCAT('taxonomy/term/', CAST(tid AS CHAR)) = src WHERE src IS NULL AND vid <> 0 ) LIMIT 0, 50 in /home/XXXXXX/sites/sites/XXXXXX.com/modules/pathauto/pathauto_taxonomy.inc on line 102.

I just commented the line: $vid_where .= ')'; to resolve the parse error.

1) My previous problem is resolved with my vocabulary mode I18N_TAXONOMY_LOCALIZE.

2) But now I have problem with my terms from the vocabulary mode Per language terms:

Pathauto doesn't use patterns for each language only neutral (all doesn't work too), so my aliases are not created for terms with language set.

And if I use the 'neutral' pattern with something like: [i18n-vocab-raw]/[i18n-catpath-raw]
Only [i18n-catpath-raw] is correctly aliased, vocab name is aliased with English only.

I still feel that these simply belong in whatever module is providing localized taxonomy as new tokens and do not belong in Pathauto.

That said, comments 71 and 72 make it clear this still needs work.

Using tokens alone will result in a confusing, inconsistent and inflexible admin interface - please see #11 and #12.

OK. I disagree with some of the assertions in #13, but won't block this work.

I agree with #13, the stuff is already translated, all we need is a localized alias for the paths.

#63: 290421-pathauto-DRUPAL-6--2.patch queued for re-testing.

I created a new patch against version branch 6--2.

I created a new patch against version 1.5.
There was a small bug #71 and I add language parameter to pathauto_create_alias() function.

It make sense to use 'i18n-*' tokens only for vocabulary mode I18N_TAXONOMY_LOCALIZE, and translated term names.
You can use 'catpath' token for other, like vocabulary mode Per language terms.

#79: 290421-pathauto-DRUPAL-6--1-5-1.patch queued for re-testing.

Test if object has language property. Maybe that is why failed testing.
Simpletest on my local site passed without fails or exceptions.

Needs to be patched against the latest D6 code, 6.x-1.x-dev in CVS.

OK, here is the patch against branch DRUPAL-6--1 in CVS.

Patch #85 works for me.

Patch in #85 does not work for me, using either [i18n-term] or [i18n-term-raw] results the component array in the url alias.
However, using [i18n-termpath-raw] is working fine (I only tested this with a single level vocabulary, e.g. one level of terms only)

There was an array_merge_recursive() for i18ntaxanomy token [i18n-term] and [i18n-term-raw].
I hope this patch correct that bug in comment #87.

Please reroll this patch without the eclipse junk in it. Thanks.

So I've split out the fixes to the bulk generation queries here: #991986: Fix bulk generation queries, so let's remove those as well.

At this point I'm wondering why this isn't patched against 6.x-2.x, where new stuff goes, and how much of this really needs to live in Pathauto. For example, all the tokens can and should live in i18n_taxonomy.module. What's the minimum we need to do in Pathauto in order to support this?

I do apologize for patch with eclipse files. Sorry about it.

Here is a new patch ;o) against 6.x-1.x-dev in CVS with new bulk generation (#991986)

Dave, you are absolutely right. It would be nice to have i18n version of catpath or termpath in i18n_taxonomy.module. We can add a new issue in Internationalization project.
I could try to write a patch against 6.x-2.x for this approach.

subscribe

@pokurek, #92: Petr, did you file any issue in the i18n queue for what Dave has proposed in #90?

@klonos: No I have not done it yet.

Subscribing

I've filed an issue in i18n queue http://drupal.org/node/1014318

Cheers

Subscribing

My 50 cents :
I've setup 4 languages :
fr -en - chinese simplified(left to right) and arabic(right to left..)
and 6 vocab with per term.
I've setup 6x2dev and got :

en :-) instruments/synthesizer

chinese :-( /zh-hans/instruments/合成器
(if you see squares it's chinese)(but vocab-name instruments should be also in chinese)

arabic <8-O ar/[i18n-vocab-raw]/المزج
which is more severe indeed !

So we still dont have vocab-name translation ...
Sob

So I patched with this mean patch:
http://drupal.org/files/issues/1014318-support-localized-taxonomy-DRUPAL...
And I got
/ar/مزاج/العدواني
and the same in chinese (cant paste...)!!!

and I must say:
EEEEEHAAAAAA !!!!!!!!!!!
It works NOW!
Really, really f. GREEEAT !
Thank you pokurek and others so much.
So Drupal 6 is 'SEO-UNICODE compliant- now !! It's a HUGE new! man!
thxxxxxxxxxx

I might be wrong but patch at #1014318: Support localized taxonomy seems to work only for "Per language terms" and does not for "Localized terms".

But patch at #92 works great for me!
Thank you pokurek.

Why doesn't it pass the test?

@anrikun:

Why doesn't it pass the test?

I guess you are referring to the testbot, right Henri? If so, then I believe that tests are now run against D7 and the patch in #92 would -of course- fail since it is for D6. I think I have filed an issue someplace for allowing tests to be run against current and previous supported versions of core. This is related I think: #961172: All D6 Core patches are failing

subscribe

would be great to find a solution for that.

hi !

I ve fixed this in a third party module :

http://drupal.org/project/metaxo

Hi. I have tested #92 on Drupal 6.22, i18n 6.x-1.9 and Pathauto 6.x-1.5, also with the patch for the new bulk generation (#991986) applied. It seems to be working ok so far, but I am still testing. Can somebody confirm if this is the final solution and if this has been commited yet? Or should this be done in i18n as part of #1014318: Support localized taxonomy?

I also have a (probably slightly off-topic) question regarding the Ubercart catalog, just in case somebody can point me to the right direction. Does anybody know what is the best way to have same path aliases for Ubercart product categories in different languages? I can do this for products but I have been looking at the issue queues for Ubercart, Pauthauto and i18n and I have found a lot of information but I am still not sure if and how this can be done for the product categories (using per language terms).

So, for example, what I want to achieve is:
en/catalog/term1/term1-1
el/catalog/term1/term1-1

which is of the form: [language]/[vocab-name]/[categoryA]/[subcategoryA-1] ...
using catalog/[catpath-raw] or [vocab-raw]/[catpath-raw]

However, even with this patch applied, the language field is not populated in the url_alias table (all works ok for standard taxonomy with this patch). This is probably because this patch is only dealing with the taxonomy, but if anybody knows how to do the same with the Ubercart catalog it would be great.

Thank you very much for all your great work.

#78: 290421-pathauto-DRUPAL-6--2-1.patch queued for re-testing.

Does somebody has paied attention to #105 ?

I've tried metaxo module: it works very well resolving this localized taxonomy pathauto issue.

Can we hope in any sort of integration/collaboration between those 2 modules?

Thank you very much.

MXT

I hope this issue gives help maybe for "Drupal 8 Multilingual Initiative" :o) and it will become as commit to the pathauto and i18ntaxonomy module.
Than this issue will be closed and metaxo module could do just its job and will not need to fix long term issues.

after the update of pathauto to 1-6 the patch #69 doesn't apply anymore.

@eiland: Please upgrade to latest 2.0 or at least latest 1.x-dev and try the latest patch at post #92. All work (especially new feature requests) goes to latest dev. Actually, things should first be fixed in 7.x-latest-dev, then backported to 6.x-latest-dev.

If the patch doesn't apply clean, then you can try to apply manually (search & delete lines that start with a "-" and add lines starting with a "+" - without the "+"): Applying a patch manually

This patch #92 is amazing.
And I don`t understand why it hasn`t been distributed with pathauto module stable versions yet.

Wow I see that is working but I'm using D7... :S

is it possible to port the #92 patch to D7 ?

thank you !!

Hi, I have tested #92 on D6 and seems to be working ok. Any plans to port this to D7? Thank you.

+1

@ShaneOnABike: please use the big green follow button on the top when you want to follow a discussion.

I would like to port this feature to D7. I have studied differences for D7, but give me a time for coding.

I promise to do it asap.

+1 for D7 localize taxonomy terms in content type

I now have a autopath for my content type "Products" set to "[node:product_section_referance]/products/[node:title]" where "product_section_referance" is a taxonomy using localized terms. But when saving a node, the url always takes the source language term name instead of the currect node's language.

I first used taxonomy with translation instead of localized, then the pathatuo was correctly, but it seems i18n has some bugs in its taxonomy translation wich made me go back to taxonomy localize option, but now the autopath failes to take the localized term

Hoping there will be a patch soon.

+1

I have exactly the same problem as timmetj

I would be great if someone could provide a patch for this issue.

Sorry but Pathauto cannot go out of its way to support something that is not in core. We can do everything we can to make sure that i18n is able to alter the tokens that it wants to, or can override the code for term bulk generation, but this patch is not at all where this is headed.

See
#1177084: Translated vocabulary names not working with Pathauto
#535522: Using translated content type from i18ncontent as a token for pathauto

I fixed it by creating a custom module to create a token of my own. I think this isn't to hard to implement but like you said it's an issue of the i18n module and not autopath. Hope they fix it pretty soon but in the meanwhile this works for me.

/**
 * Implements hook_token_info().
 */
function i18n_tax_on_nodes_token_token_info() {

  // Taxonomy term related variables.
  $term['i18n-setions'] = array(
    'name' => t("Tax Term (localized)"),
    'description' => t("The name of the taxonomy term attached to the node."),
    'needs-data' => 'node',
  );

  return array(
    'tokens' => array(
      'node' => $term,
    ),
  );
}

/**
 * Implements hook_tokens().
 */
function i18n_tax_on_nodes_token_tokens($type, $tokens, array $data = array(), array $options = array()) {
  $replacements = array();
  $sanitize = !empty($options['sanitize']);


 if ($type == 'node' && !empty($data['node'])) {
    $node = $data['node'];
    $lang = $node->language;
    $tax = taxonomy_term_load($node->product_section_referance['und']['0']['tid']);
    
    foreach ($tokens as $name => $original) {
      switch ($name) {
      	
        case 'i18n-setions':
        	if($lang == 'fr'){
        		$name = i18n_taxonomy_term_name($tax, $langcode = 'fr');
          		$replacements[$original] = $sanitize ? check_plain($name) : $name;
        	}
        	elseif($lang == 'nl'){
        		$name = i18n_taxonomy_term_name($tax, $langcode = 'nl');
          		$replacements[$original] = $sanitize ? check_plain($name) : $name;
        	}
        	else{
        		$name = $tax->name;
          		$replacements[$original] = $sanitize ? check_plain($name) : $name;
        	}
          break;
      }
    }
  }

  return $replacements;
}

I just get the $lang from the node object and than just get the translation of my taxonomy field. I admit the code can be bettered so it can be used more global but I just needed it for 1 taxonomy.

Hope it helps somebody with the same problem

Hello GertVdb,

can you please elaborate on your solution? where should I place this code?

Thank you

Hi,
I've taken #92 and ported it to D7.
The tokens part isn't necessary anymore (handled by i18n_taxonomy).
Working fine for me (it allows to enter different patterns for each languages, and terms aliases are correctly generated).

zylootino, he wrote his own token in his own small module. you can add tokens yourself with using token api. i think there is an example too in the examples module.

patch #124 not working for me, url aliases are being generated as language ALL

related #1574628: [term:parents:join-path] not woking with multilanguage vocabualries

i18n only adds support for core drupal tokens. i created a small module myself to add a translated taxonomy path for every language. maybe it helps/inspires.
http://drupal.org/project/pathauto_i18n_taxonomy

@jdanthinne:
Path at #124 does not work. I wonder how it could as it only acts on settings form. Are you sure your patch is complete? It really seems that you skipped some files.

Patch #124 works fine for vocabularies with Translated terms but doesn't work for Localized terms. Translated term has it's own Path (either generated by pathauto or manually set), localized terms do not (not in the GUI anyway). I would go for Translated terms, but there's too much overhead in my case — all languages have the same terms, so Localized terms fit great.

I know I am not helpful much, but then again maybe somebody will think about this for drupal 8 and finally languages other then english wouldn't be so much neglected.

I am drupal pro for 5 years and whenever I had to do a i18n site I had to pull hair out and went crayze.
It's just so hard to put a proffesional drupal multilanguage solution. Currently this taxonomy is a big problem, panels also have to be hacked just to translate title, or build one for each language. For good site, you also need SEO, breadcrumbs. Meta tags in d6 just didnt care about i18n. Views and taxonomy you need a separate module which wasnt there for long in d6. Menus in d6 also had problems, now in d7 it's finally ok
and easier to work with. Seems that many modules when designed just didn't think of need to translate everything so people can build multilanguge site that also has proper URL's, breadcrumbs, meta tags, menu items, titles and labels.

Tried to regenerated the URL aliases for my categories with the following for the french pattern:
cat/fr/[term:i18n-parent:parents:join-path]/[term:i18n-name]

I tried to generate the following: cat/fr/categorie/sous-categorie , but it generated cat/sous-categorie.

Maybe it's worh saying that I firstly created all the categories in english then tried to translate them in several languages, but it seems that it never apply the language prefix I want, and I still have the issue for sub-categories not showing its parent(s).

Changing status again

Patch in #124 works only for:

it allows to enter different patterns for each languages

And this is a good start, so we can insert path prefixes per language.

Unfortunately the correct i18n taxonomy path generation still is not resolved, so in my case using patch in 124 I can now set for example:

Pattern for all Customer type paths in english -> professionals/[term:i18n-parent:parents:join-path]/[term:i18n-name]

And:

Pattern for all Customer type paths in Italian -> professionisti/[term:i18n-parent:parents:join-path]/[term:i18n-name]

Results:

in English:
professionals/airbrushers -> WRONG! it should be professionals/decorators/airbrushers

in Italian:
professionisti/airbrushers -> WRONG! it should be professionisti/decoratori/aerografisti

So, regardless errors above (as in #129 and related to #1574628: [term:parents:join-path] not woking with multilanguage vocabualries) per language path prefixing works correctly.

*** Removed as this was just a howto not related to the issue - added to docs instead ***

To anyone looking for a workaround, see also http://drupal.stackexchange.com/q/28402/10086

Can't believe that no one can't solve this problem since August 2, 2008. See that this module is used by 487928 sites.

This is very devastating to the Drupal community, Drupal CMS. So i'm calling those who called them self Drupal PRO Developers to solve this issue.

This is the reality...

You can't translate all urls and nowdays this is one of the basic things.

It works for me with a configuration like this :
term/[term:i18n-vocabulary]/[term:parents-all:2:i18n-name]/[term:parents-all:1:i18n-name]/[term:i18n-name]

pathauto : 7.x-1.2
i18n : 7.x-1.8

In action here :
http://www.ilemaurice-bonplan.com
exemple :
http://www.ilemaurice-bonplan.com/term/region/west/rivière-noire/le-morne
http://www.ilemaurice-bonplan.com/fr/term/région/ouest/rivière-noire/le-morne

srobert72 I tried your setup and it didn't work. Pathauto generate some path and that paths are on Language "All" - PRINTSCREEN

NOTE: My vocabularies are in Localize Mode. Terms are common for all languages, but their name and description may be localized..

If I want to have paths on both language I need to change path MANUALY from Language "ALL" to Language "SH" and than manualy enter new second language alias manualy.

However Pathauto works for nodes and it translate all taxonomy token that are in the url

Duplicate issues can be found at:
https://drupal.org/node/1964666
https://drupal.org/node/2021255
https://drupal.org/node/1993462

Also FOUND THAT Someone has made module https://drupal.org/node/1615184 - THis module works GOOD

So why don't someone merge it into pathauto???

@blackandcode
OK I understand why we have different results. I use another module :
https://drupal.org/project/pathauto_i18n_taxonomy

Attached patch (based on #124) includes support for entity translation. Note that the entity translation system is part of core - the contrib module only adds a UI to enable it and navigate translations.

No news on this? :(

Duplicate issues can be found at:
https://drupal.org/node/1964666
https://drupal.org/node/2021255
https://drupal.org/node/1993462

I marked all those issues duplicate of this one, since this patch seems to be the best-implemented and this issue has the most traction.

I don't believe it's the responsibility of Pathauto module to support localized taxonomy at all, because it supports core only, and core does not support localized taxonomy out of the box. I would encourage modules like i18n to implement hooks or alter hooks to make this possible. If it's not possible to alter the right parts, I want to know that, and we can fix that upstream in Pathauto.

I know this is going to be unpopular, but I will be the first person to link to the appropriate solution in another module from the Pathauto project page to help direct people.

Patch provided in #138 works great for me, using ONLY entity_translations for taxonomies (no 18n_taxonomy)

Thank you very much!

I am facing following problem when we use entity_translations for taxonomies (and no 18n_taxonomy) :

-> When we add or update node then in term referenced fields I can not see translated terms , please suggest ?

Thanks!

This is a re-rolled patch based on pathauto 7.x-1.3

To anyone looking for a workaround, see also http://drupal.stackexchange.com/q/28402/10086

Another interisting link:
http://www.drupaldump.com/multilanguagei18n-taxonomy-and-url-aliases-pat...

For me, what works best is this module: Pathauto i18n Taxonomy For this to work, you have to translate taxonomies via Entity Translation module.

@Dave Reid Could you add a link to "Pathauto i18n Taxonomy" module on the project page? It would be much easier and faster to find out what you have to do to have translated taonomy paths. Thanks!

i wrote that module. but be aware that it is old and i wrote it when i was pretty noob :)
it has some issues and is unmaintained, so be careful.

@marcoka Your module is very cool. Why you decided not to mantain it anymore? It's the best solution I've found!

because it was initially for my texturesite www.texturecase.com but that now doesnt use i18n no more because i nuked myself out of the seo-orbit when i translated it to english. and the project also hasnt found much users, so the server costs me more than the ads give me :D

@marcoka But If you are still a drupal developer, keeping this project up to date gives you some reputation

I get an interesting behavior.

1. I type in the term name
2. at the bottom of the page I hit Save and translate
3. then I click translate and type in the localized term name and click save
4. What I have now at the English side as URL: /english-voc-name/english-term-name
5. and at the localized side URL: /localized-voc-name/english-term-name

The same result as much as I repeat the steps BUT

1. After these steps in the taxonomy vocabulary, click edit term, scroll down the page click Save and translate (not the Translate tab at the top) and stop there, what I get then is:
2. at the English side: /english-voc-name/english-term-name
3. at the localized side: /localized-voc-name/localized-term-name

If I continued after Save and translate and click the edit link and then the button save, it reverts back where I don't get the localized term name in the URL.

Let's try to get this committed to i18n instead, given #141?

Reuploading a reroll of #144 against pathauto 1.3

Recently (today) the simpletest for HEAD was fixed.

queue patch by @stefan.r for simpletests

Good news is, our simpletests are now working on HEAD, now to get this patch to work.

The recent changes to dev 7.x-1.x require some refactoring of the patch.

Needs work.

Thanks, keep up the great work everyone!

Hello,

This patch works for me with pathauto 7.x-1.3 (1444232655).
There is just a copy issue because we won't manage patterns for node but for vocabularies.

So .. "applies to all %vocab-name node types" ... must be changed to .. "applies to all %vocab-name terms" ...

Here you can found an updated version of the patch provided by robertom then stefan.r

Kind regards,

This patch is for pathauto.module , needs attention of the pathauto maintainers.

#159 does not work for me if I'm using localized terms ( "Terms are common for all languages, but their name and description may be localized." ). Is it a bug or "works as designed"? Other experiences?

D7.53
Pathauto 7.x-1.3
Taxonomy translation (i18n_taxonomy) 7.x-1.14

Patch #159 works for me partially. Finally a step closer to have fully translated term hierarchy. Thanks! :)

Not working for untranslated taxonomies though where you just want to use different path patterns for different languages.

#159 works
entity translation