Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

Customising the CMS

URLSegment transliteration

Go to End

14 Posts   2717 Views


14 March 2010 at 11:35am Community Member, 4 Posts

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');
   return $fields;

I hope that anybody will find this useful,


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

Attached Files

14 March 2010 at 11:46am Community Member, 4 Posts

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',



6 May 2010 at 1:12am (Last edited: 6 May 2010 2:38am), Community Member, 40 Posts


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


18 May 2010 at 8:10am Community Member, 4 Posts


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 ( 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.



18 May 2010 at 6:21pm Community Member, 40 Posts

To be translitaration working:

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

class MySiteTreeDecorator extends SiteTreeDecorator {
   public function updateCMSFields( FieldSet &$fields ) {
      Requirements::javascript( project() . '/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


28 May 2010 at 8:34am Forum Moderator, 801 Posts

I'm not sure if you've seen the transliteration that was added into core last week:

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


28 May 2010 at 7:57pm Community Member, 40 Posts

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

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.


31 May 2010 at 9:15am Forum Moderator, 801 Posts

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 ;)

Go to Top