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 /

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo, swaiba

URLSegment transliteration

Go to End

14 Posts   3297 Views


Community Member, 42 Posts

1 June 2010 at 1:38am

Edited: 01/06/2010 1:50am

>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?


Forum Moderator, 801 Posts

1 June 2010 at 8:21am

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

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


Community Member, 4 Posts

1 June 2010 at 9:45am


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.



Community Member, 42 Posts

1 June 2010 at 6:34pm

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


Community Member, 42 Posts

1 June 2010 at 6:44pm

Edited: 01/06/2010 9:15pm

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


Community Member, 5 Posts

31 March 2011 at 4:48am

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

Go to Top