>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" - http://www.silverstripe.org/ForumMemberProfile/show/8091.

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

Hello,

Dat files is created from this source http://drupal.org/files/issues/i18n-ascii-full.txt.
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.

Regards,
Ales

As you can see:

1. method is VERY FAST http://www.silverstripe.org/customising-the-cms/show/280895?start=8#post285417
2 The .dat files has VERY BIG SET OF CHARS http://drupal.org/files/issues/i18n-ascii-full.txt

Security:
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