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.
Comment | File | Size | Author |
---|---|---|---|
#17 | 973908-pathauto-cleanstring-langauge-aware.patch | 4.12 KB | Dave Reid |
#14 | 973908-pathauto-cleanstring-langauge-aware.patch | 4.12 KB | Dave Reid |
#7 | 973908-pathauto-cleanstring-language-aware.patch | 2.68 KB | Dave Reid |
Comments
Comment #1
porg CreditAttribution: porg commented@ 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!
Comment #2
smk-ka CreditAttribution: smk-ka commentedUnfortunately 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.
Comment #3
amateescu CreditAttribution: amateescu commentedMoving to Pathauto.
Comment #4
Freso CreditAttribution: Freso commentedHuh. 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.Comment #5
Freso CreditAttribution: Freso commentedHm. 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.
Comment #6
Dave ReidYeah 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().
Comment #7
Dave ReidThis is a start.
Comment #8
Dave ReidComment #9
Dave ReidMarked #1596252: Wrong language code used for transliteration when editing translations with i18n_sync as a duplicate of this issue.
Comment #10
Freso CreditAttribution: Freso commented#7: 973908-pathauto-cleanstring-language-aware.patch queued for re-testing.
Comment #11
Freso CreditAttribution: Freso commentedI 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.
Comment #12
Freso CreditAttribution: Freso commentedAccording 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.
Comment #13
Freso CreditAttribution: Freso commentedComment #14
Dave ReidComment #17
Dave ReidComment #18
Dave ReidCommitted #17 to 6.x-2.x. http://drupalcode.org/project/pathauto.git/commit/6109247