We're working on making pathauto use transliteration for, well, transliteration, (see #247758: Use Transliteration module for transliteration) but there is one outstanding bug that Pathauto didn't use the language-specific rules before. Letting Transliteration handle this means that Transliteration should now use the language-specific rules, but I don't see how that Transliteration could possibly know the language from a regular transliteration_get()
call (if it does know, sorry for opening this, and I'll definitely take a more in-depth look at the code!), so I'm proposing to simply add a third parameter to transliteration_get()
, e.g. $lang
(which could be NULL
or ''
by default), for the language code.
Comment | File | Size | Author |
---|---|---|---|
#5 | transliteration-language.patch | 183.88 KB | smk-ka |
#1 | transliteration-language.patch | 6.14 KB | smk-ka |
Comments
Comment #1
smk-ka CreditAttribution: smk-ka commentedHere you go. Note that the language handling code was completely broken before this patch (was still using $locale from D5 instead of the new $language object). The function signature has been changed as you proposed.
Additionally,
transliteration_process()
is now a public function, since in some circumstances it might be faster to call it directly, thus avoid the overhead of repeatedly calling require_once() (might be useful when batch updating url aliases).Comment #2
Freso CreditAttribution: Freso commentedTried making a "PHP code" node on my test site with the following code:
In both cases, it got transliterated to "O o". I then tried to actually enable German as a language for the site, flushed the caches, and tried again. Same result.
Comment #3
Freso CreditAttribution: Freso commentedOh, and just for the sake of completeness, my expected result was "Oe oe" (based on
'de' => array(0xC4 => 'Ae', 0xD6 => 'Oe', 0xDC => 'Ue', 0xE4 => 'ae', 0xF6 => 'oe', 0xFC => 'ue'),
in data/x00.php).Comment #4
Freso CreditAttribution: Freso commentedHm. And another update. When looking at the node with site language set to Danish or English, at least it does transliterate to "o". Seeing the node in German shows "?" in their place... replacing the hex values with their base-10 numerical value doesn't help, but commenting out the "de" line does do the trick of at least making it "o" instead of "ö"...
Comment #5
smk-ka CreditAttribution: smk-ka commentedThanks for testing and sorry for wasting your time... there was actually more broken than I thought it would regarding the language specific mix-ins. I've now rewritten quite a bit of the code, and your two simple tests seem to work (finally).
Comment #6
netbjarne CreditAttribution: netbjarne commentedId be happy to test, but I'm not too good at interpreting .patch files.
Could you created a patched package and attach it for easy download?
Comment #7
Freso CreditAttribution: Freso commentedThe test above works fine with the new patch. I also added somewhat to the complexity:
And added a line
'da' => array(0xD6 => 'Ø'),
to x00.php. I then looked at it in the regular interface. German and Danish got replaced as they should ("Ø o" and "Oe oe") and the English kept its text. Looking in Danish, the "normal transliteration" was "Ø o", with Danish and German as before. Expected results when viewing German interface as well. I also looked through the code, and there weren't anything wrong that I could spot. So, all in all, marking this RTBC. :)Comment #8
smk-ka CreditAttribution: smk-ka commentedSorry for being unresponsive. Patch has been committed to DRUPAL-6--2 and backported to DRUPAL-5--2.
Comment #9
Anonymous (not verified) CreditAttribution: Anonymous commentedAutomatically closed -- issue fixed for two weeks with no activity.