Include the slug transliteration plugin into the core of GS

[yojoe]

Thus I'm more for str_replace with array using assignment operators.
But if you already use strtr succesfully, I have nothing against this way

Now that you mention it: I didn't try it and I suppose it won't work with UTF-8 :-(

However, I would still define the translation as described above in the language files (no additional variable, translate plugin works, ...) and then split it into arrays using a UTF-8 function.

there's another argument for str_replace: Martijn's translit plugin uses it successfully
From what I've found strtr() needs chars in latin1 encoding (maybe from extended char tables), and thus strings would have to be converted from utf. The working but harsh method is to convert using chr along with preg replace <- a true pain in the ***.

PHP: the greatest pains are utf-8, the automatic escaping of quotes and finding out, if the string/array is the first parameter or not in a specific string or array function. Feel free to add to this list ;-)

...encoding/decoding, forcing, converting, switching between different char sets, setting locales ... there are only problems with all those special chars. Adding to them databases ...

After looking at all existing php functions in regards of character encoding, I became stupid.
Existing solutions barely works, every system needs own approach <- the essence of multilingual web systems.