I found out that build in transliteration is quite limited, so I decided to upgrade it with full transliteration (mapping all utf-16 character to corresponding latin char).

Old behaviour:
Page title γειά κόσμο (hello world in Greek) would get transliterated to empty string.

New behaviour:
Page title γειά κόσμο gets transliterated to geia-kosmo which makes a lot more sence.

To use this patch, you need to make following changes:
1. extract files in the attachment to your root folder
2. inside mysite/code/Page.php in class Page you need to define method like bellow:

function getCMSFields() {
$fields = parent::getCMSFields();
// we need to override default behaviour by replacing javascript callbacks defined in UpdateURL.js
Requirements::clear(SAPPHIRE_DIR . '/javascript/UpdateURL.js');
Requirements::javascript('mysite/javascript/UpdateURL.js');
return $fields;
}

I hope that anybody will find this useful,

Regards,
Ales

ps. If anybody finds more elegant solution to integrate this patch into silverstripe I would love to hear about it.

I forgot that you also need to add lines bellow to your mysite/_config.php file.

// this goes to mysite/_config.php
Director::addRules(10000, array(
'Transliterate/$Action/$ID' => 'Transliterate_Controller',
));

Regards,
Ales

Hi,

can you say me, please which version are you usuing?
I'm now testing with SS 2.4 and not works.

I've the same troubles for Czech, Slovak translation.
If it works, say me, please how.
I would like to use to transliterate globally for all titles and mkdir dirs/files too.

Can you help me or contact me at jaroslav.stika@gmail.com?

Hello,

Sorry for very late answer, but I have been very busy at work.
I tried the patch myself using latest and greatest version 2.4 (http://silverstripe.org/silverstripe-2-4-release-a-significant-step-forward/) and it works flawlessly. Maybe I forgot to mention that this patch is substitute for old behaviour meaning that new url is generated when you change page title in the cms interface.

If you need any more assistance please let me know.

Regards,
Ales

To be translitaration working:

I had to add DataObject::add_extension('SiteTree', 'MySiteTreeDecorator');

class MySiteTreeDecorator extends SiteTreeDecorator {
public function updateCMSFields( FieldSet &$fields ) {
Requirements::clear('sapphire/javascript/UpdateURL.js');
Requirements::javascript( project() . '/javascript/UpdateURL.js');
}
}

becouse

Requirements::clear('sapphire/javascript/UpdateURL.js');
Requirements::javascript( project() . '/javascript/UpdateURL.js');

cannot be called from Page.php init(). The ones can be called, but doesnt work'.

After that it works, but strangely:
When I use variable (from $_GET, $_POST, $_REQUEST) it's ok.
When I use variable from cs_CZ lang file, it's bad.
I fail to find out what code page is used (not iso-8859-1, not iso-8859-2, not CP1250)

My OS Win 7 Ultimate 64 bit (Czech locale), php 531, Apache 2.2.15

I'm not sure if you've seen the transliteration that was added into core last week: http://open.silverstripe.org/browser/modules/sapphire/branches/2.4/core/model/Transliterator.php?rev=104671

You can change the implementation via dependency injection: Object::use_custom_class('Transliterator', 'MyTransliterator').

Hi,
I successfully implent your Transliterate class for URLSegment, mkdir, Upload file.
I tested for cs_CCZ, sk_SK, ru_RU, de_DE.
From your class Transliteare I made module Transliterate.
It works great for my need!
I'm now most satisfied!

I don't think that

http://open.silverstripe.org/browser/modules/sapphire/branches/2.4/core/model/Transliterator.php?rev=104671

is good and safe solution.
I wrote similar code 4 years ago.
It is not usable and safe, I've troubles e.g.: with char "ž".
Look to the attachment, please.

Could you provide some comparisons between the effectiveness of your *.dat based implementation, vs. our array mapping? Perhaps through some unit tests?

It looks like your mapping is a bit more extensive, but how is it conceptually different? (e.g. does it map unicode planes automatically somehow?). If you implement your module as a subclass of Transliterator (with toASCII() method), you can just exchange the built-in functionality in core.

By the way: Your Transliterate controller is unsecured, which is a bit odd - not security critical, but basically you allow the world to use websites with this module as a free transliteration service ;)