It is very uncomfortable that every time the pathauto module is updated or installed in a new system, one has to manually copy the i18n-ascii.example.txt into place. It's very easy to forget this during upgrade, and as a result, new URLs go bad (contain unwanted UTF-8 characters).

It would be much better if a) the i18n-ascii.txt was present by default with the correct name and pathauto would remember the setting to use it, or b) the whole file would be replaced by something stored permanently in the database.

Also, there are some very silly things in i18n-ascii.example.txt for us Finnish people. We never, i repeat _never_, transliterate the letters Ä and Ö into something like "AE" and "OE". That just looks silly. Rather we want to strip away the umlauts, so they become "A" and "O" and look normal to us in URLs. This is already so for the letter Å. I am hoping this could be changed into the default i18n-ascii.example.txt, so we wouldn't have to edit it every time. I am attaching the modified version of i18n-ascii.example.txt that I hope to become a new default.

CommentFileSizeAuthor
i18n-ascii.txt5.21 KBkennu
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

deshilachado’s picture

Hi kennu,

in German it is, even if it is the first letter of a word, absolutely common to transliterate
ä to ae,
ö to oe,
ü to ue and
ß to ss.
Probably that is where this transliteration proposal comes from...

But I agree to your proposals a) and b)

greggles’s picture

As this discussion with deshilachado shows, there is no perfect file for all purposes. The file is meant to be customized.

So, if the project files included the file with the "correct" name then people would be quite likely to download the new version of Pathauto, extract it into their folder, and overwrite their site-specific file with the default one which could overwrite hours of work. I don't think that's a good feature.

Proposal b is handled in Pathauto 6.x-2.x which relies on the Transliteration module.

I would mark this "by design" or "won't fix" but defer to Freso.

Freso’s picture

Status: Active » Closed (won't fix)

"Won't fix", as we don't want a Pathauto update to reset a customised i18n-ascii.txt, and it is currently possibly to customise per Pathauto install in 6.x-1.x and earlier and possible to customise per language (through the Transliteration module) in 6.x-2.x.

Drupal Berlin’s picture

honigferd’s picture

Then why not put the file into the sites files folder?

It is really, really frustrating to having to babysit files in the modules folders, stumbling upon the same issues over and over again when upgrading. :-S

Aveu’s picture

Status: Closed (won't fix) » Active

I like this idea but I would go you one better... Create a separate but dependent i18nASCII module whose sole function is to help update the file in the pathauto directory (by calling it from pathauto with a parameter). The parameter would normally be the user's language which in turn would be the last qualifier in for an i18n filename. Pathauto could check first to see if the desired file is the one already in place to save a module call.

Using this would allow many good things such as:

* users can create and share "standard" libraries of i18n files for various langauges like i18n._nl, i18n._de, etc
* users can create and share "special" libraries of i18n files for customized langauges like i18n.tolkien, i18n.klingon
* pathauto can dynamically choose/use the i18n file that is appropriate to the user's language at the time of aliasing

I am going to mark this active (I know it will be changed back) just to kick this idea around. If there is sufficient support I will create a new issue to start work on such a module (note that I am not saying I will personally create the module -- I am still learning Drupal and PHP so I don't know if this is within my skills -- but I will try and do whatever I can).

greggles’s picture

Status: Active » Closed (won't fix)

@Aveu - http://drupal.org/project/transliteration :) Someone beat you to it. That module is used in Pathauto 6.x-2.x instead of the i18n-ascii.txt system.

donquixote’s picture

Status: Closed (won't fix) » Active

See #823648-10: Allow multiple locations for i18n-ascii.txt to make it drush-up-friendly.

The custom i18n-ascii.txt will be moved into an external location, with the module folder as a fallback. This is a chance to use a standard file shipped with the module for default transliteration rules (at least for the many western european languages that only need a few characters transliterated), and use the external location for permanent overrides.

EDIT:
The default "fallback" file could be named "i18n-ascii.default.txt", to make it less likely that the custom file gets lost with a module update.

Dave Reid’s picture

Status: Active » Closed (won't fix)

Restoring status