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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

porg’s picture

@ 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!

smk-ka’s picture

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.

amateescu’s picture

Project: Transliteration » Pathauto
Version: 6.x-3.0 » 6.x-2.x-dev

Moving to Pathauto.

Freso’s picture

Version: 6.x-2.x-dev » 7.x-1.x-dev
Assigned: Unassigned » Freso

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.

Freso’s picture

Assigned: Freso » Unassigned

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.

Dave Reid’s picture

Title: Transliteration method chosen from interface language rather than node content language » pathauto_cleanstring() lacks language context

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().

Dave Reid’s picture

Status: Active » Needs review
FileSize
2.68 KB

This is a start.

Dave Reid’s picture

Assigned: Unassigned » Dave Reid
Dave Reid’s picture

Freso’s picture

Freso’s picture

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.

Freso’s picture

Status: Needs review » Patch (to be ported)

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.

Freso’s picture

Version: 7.x-1.x-dev » 6.x-2.x-dev
Assigned: Dave Reid » Unassigned
Dave Reid’s picture

Issue summary: View changes
Status: Patch (to be ported) » Needs review
FileSize
4.12 KB

Status: Needs review » Needs work

The last submitted patch, 14: 973908-pathauto-cleanstring-langauge-aware.patch, failed testing.

The last submitted patch, 14: 973908-pathauto-cleanstring-langauge-aware.patch, failed testing.

Dave Reid’s picture

Status: Needs work » Needs review
FileSize
4.12 KB
Dave Reid’s picture

Version: 6.x-2.x-dev » 7.x-1.x-dev
Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.