| Project: | Pathauto |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | patch (to be ported) |
Issue Summary
I use Transliteration in PathAuto (through the option "Transliterate prior to creating alias") on an multilingual site to achieve ASCII-only URLs.
Action: Creating node with the content language XX in the interface language YY.
Buggy result: Transliteration method of YY gets applied!
Suggestion: Transliteration method of XX shall be applied! Why? Because the content language and its particular transliteration method shall be reflected in the URL. The interface language which was used at the time of node creation, is irrelevant for that matter.
How I realized that bug?
I use English as my interface language as I am used to its terminologies from the Drupal community discourse.
I created a German page "Förderung", and it unexpectedly got the URL alias "/de/forderung" instead of the expected "/de/foerderung".
As a test I created "Mötorhead" both as German and English node, resulting in "/de/motorhead" (false) and "/en/motorhead" (correct).
Only when I changed the interface language to German, I could achieve "/de/moetorhead" (correct, if it was a German word) but then the English alias "/en/moetorhead" was false.
Comments
#1
@ Maintainer: Btw, I tested the same scenario with the feature "filename transliteration after file uploads", and here it works as expected! Meaning that it considers the node content language rather than the interface language. I am not completely sure about the causalities, therefore for completeness I also tested and mentioned this function!
#2
Unfortunately this is a bug within pathauto, which doesn't extract and pass the correct source language of the processed object to the transliteration function. It's the intended behavior to fall back on the current display language of the site instead.
#3
Moving to Pathauto.
#4
Huh. I was sure I had dealt with this when I implemented it. Anyway, the culprit seems to be that
pathauto_cleanstring()isn't language aware. I'm brewing on a patch as I write.#5
Hm. I can't do this without having a dev environment, which I haven't yet set up on this system. If Super Dave passes by and fixes this before I get around to it, then great. ;) If not, I'll come back to it later.
#6
Yeah this is something we need to fix for 7.x-1.x and 6.x-2.x. We have language context but we don't pass it to pathauto_cleanstring().
#7
This is a start.
#8
#9
Marked #1596252: Wrong language code used for transliteration when editing translations with i18n_sync as a duplicate of this issue.
#10
#7: 973908-pathauto-cleanstring-language-aware.patch queued for re-testing.
#11
I don't know whether this still applies, but I can't see anything wrong with the code. Queued for re-testing to see if it still passes, if not, I'll try and get around updating it.
#12
According to the tests, the patch doesn't break anything, and from my manual review, the code looks clean too. Committed to 7.x-1.x.
#13