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


14 Posts   2715 Views


1 June 2010 at 1:38am (Last edited: 1 June 2010 1:50am), Community Member, 40 Posts

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

I don't build .dat file, owner is "thinman" -

>It looks like your mapping is a bit more extensive,

1. Yes, it's big true.

>but how is it conceptually different?

2. Your $table array has very limited set of chars
3. Transliterator.php (whole file) has to be saved as UTF-8. Don't forget for win OS's users (less experienced).

>If you implement your module as a subclass of Transliterator (with toASCII() method), you can just exchange the built-in functionality in core.

3. Yes it's true, but I'm using official SS 2.4 (not svn) version and I want to use only official version.
What can I say or I explain problems to my clients?

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

What do you mean? Director::addRules is insecure?


1 June 2010 at 8:21am Forum Moderator, 801 Posts

>What do you mean? Director::addRules is insecure?

No your controller is - addRules() just matches URLs with its controllers, but doesn't do authentication.


1 June 2010 at 9:45am Community Member, 4 Posts


Dat files is created from this source
Main difference lies in speed and memory consumption. Whole dat file is never read to memory (only little chunks are read), search is done using binary search - which ensures logarithmic search time.



1 June 2010 at 6:34pm Community Member, 40 Posts

Thanks for link. I found it yesterday, I was former perlist.


1 June 2010 at 6:44pm (Last edited: 1 June 2010 9:15pm), Community Member, 40 Posts

As you can see:

1. method is VERY FAST
2 The .dat files has VERY BIG SET OF CHARS

1. I thought, if its used from backend it's secure too.
2. OK, I completed it.

I think, this solution (2in1) rid many non ASCII users troubles of converting strings to ASCII:
a) URLSegmemt
b) dirnames - add/edit
c) filenames - uplad/edit/rename


31 March 2011 at 4:48am Community Member, 5 Posts

I'm looking forward to see support for converting non ascii characters to ascii in the next release! :)