e.g. umlaut "ü" translates to u and not ue as expected.

I realise that I somehow have to get the transliteration to use the German transliteration tables in the data/00x ** php files
but it always seems to use the English table.
I have German set as the default language for the website in admin/config/regional/language.
Is there another place to set the langauge to get the correct table used?


Peacog’s picture

I had the same problem, although in my case English is the default language. When English is the current language, ü transliterates to u. To get ue I have to switch language so that German is the current language.

calliandra’s picture

I had the same problem.
In my case, I had the site's default language set to German, but had my user settings set to English.
This must have triggered the "English-flavor" transliteration of Umlauts, because when I changed that to German as well, transliteration began working as expected, i.e. using the German transliteration set.


watchdog’s picture

Category: support » bug

I had both the standard and the admin's user language set to German, but it still did not work correctly (i.e. "ü"->"u"). I figured out that you have to use the german version of the admin page ("/de/admin/config/search/path/update_bulk") for doing the bulk update in order to make it work correctly.

yannickoo’s picture

I don't have a German language, it's english only. It should be possible to change the language for Pathauto only with hook_pathauto_pattern_alter. You could change the language to 'de' there.

oschuetze’s picture

With "transliteration" and "pathauto" running, there is only a simple replacement, e.g. "ü" -> "u". But I need a replacement like "ü" -> "ue".

@yannickoo: How can I change the language? I've added

$context['language'] = 'de';

to hook_pathauto_pattern_alter and cleaned all caches - but nothing happend. Any other Idea?

yannickoo’s picture

Okay, you are right that doesn't work. Anyways I could find out how to get "ae" instead of "a" for an "ä". The clue is that you have to edit the entity in german then Transliteration searches for the proper replacements.

I don't know how we could fix that exactly because the one way would make use of the entity language so if your entity is german you want proper replacements ("ae" instead of "a" etc.). This is not so easy because the functions are called in following order:

  1. pathauto_create_alias($module, $op, $source, $data, $type = NULL, $language = LANGUAGE_NONE)
  2. pathauto_clean_token_values(&$replacements, $data = array(), $options = array())
  3. pathauto_cleanstring($string) (no language is passed)
  4. transliteration_get($output) (at this place the entity language could be passed)
  5. _transliteration_process($text, $unknown = '?', $source_langcode = NULL)

I think the easiest way to would be changing the replacement pattern in the <a href="http://drupalcode.org/project/transliteration.git/blob/refs/heads/7.x-3.x:/data/x00.php">x00.php</a> file so that it doesn't matter which language you are using. Replace "ä" with "ae" is common.

What do you think?

yannickoo’s picture

Version: 7.x-3.1 » 7.x-3.x-dev
Component: Miscellaneous » Code
Category: Bug report » Task
Issue summary: View changes
Status: Active » Needs review
899 bytes
amateescu’s picture

We cannot hardcode language specific variants like that, that's the whole point of having the mechanism to support language overrides per language..

dokumori’s picture

I'm working on a German site under a multisite setup, which also holds the same version of the site in other languages. While the German website's default language needs to be set to British English, transliteration of umlauts still needs to work.

In order to set the site's 'preferred' language arbitrarily, I've defined a constant 'TRANSLIT_SITE_LANG' in settings.php of the German site, then applied this patch to the module's .inc file. The patch allows you to separate a site's default language and a language code for transliteration.

Not sure if the maintainer wants to apply this patch to the module, but posting anyway as some people may find it useful.

Ronino’s picture

It seems like taxonomy terms don't have a language by default and there is no i18n support for terms in core (see #290421: pathauto patch to provide localized and entity translated taxonomy through i18n). However you can trick transliteration into using your site's default language for all terms by implementing a language callback for taxonomy terms like so:

 * Implements hook_entity_info_alter().
function MODULE_entity_info_alter(&$entity_info) {
  $entity_info['taxonomy_term']['language callback'] = 'MODULE_entity_language';

 * Language callback for the taxonomy_term entity. Returns the site's default
 * language code for taxonomy terms to transliterate their aliases based on that
 * language instead of no language (which corresponds to English) as returned
 * for taxonomy terms by entity_language().
 * @return string
 *   Language code for the given entity or NULL if there is none.
function MODULE_entity_language($entity_type, $entity) {
  if ($entity_type == 'taxonomy_term') {
    return language_default('language');
  else {
    return entity_language($entity_type, $entity);