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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

smk-ka’s picture

Assigned: Unassigned » smk-ka
Status: Active » Needs review
FileSize
6.14 KB

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

Freso’s picture

Status: Needs review » Needs work

Tried making a "PHP code" node on my test site with the following code:

print 'Normal Transliteration transliteration: '. transliteration_get('Ö ö', '?') .'<br />';
print 'German Transliteration transliteration: '. transliteration_get('Ö ö', '?', 'de');

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.

Freso’s picture

Oh, 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).

Freso’s picture

Hm. 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 "ö"...

smk-ka’s picture

Status: Needs work » Needs review
FileSize
183.88 KB

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

netbjarne’s picture

Id 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?

Freso’s picture

Status: Needs review » Reviewed & tested by the community

The test above works fine with the new patch. I also added somewhat to the complexity:

$string = 'Ö ö';
print 'String used: '. $string .'<br />';
print 'Normal Transliteration transliteration: '. transliteration_get($string, '?') .'<br />';
print 'Danish Transliteration transliteration: '. transliteration_get($string, '?', 'da') .'<br />';
print 'German Transliteration transliteration: '. transliteration_get($string, '?', 'de');

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

smk-ka’s picture

Version: 6.x-1.0 » 6.x-2.0
Status: Reviewed & tested by the community » Fixed

Sorry for being unresponsive. Patch has been committed to DRUPAL-6--2 and backported to DRUPAL-5--2.

Anonymous’s picture

Status: Fixed » Closed (fixed)

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