<p>I'm worried that some users will confuse Transliteration with Inflector, and use the wrong filter. Perhaps the class name should be something along the lines of Zend_Filter_ReplaceI18nChars or something similar that lay-people will understand?</p>

<p>Just added cyrillic transliteration using transliteration table.</p>

<p>Please update from SVN.</p>

<p>Martin H.</p>

<p>Using this filter I would suggest that it is able to recode</p>
<ul>
<li>ASCII to UTF-8</li>
<li>UTF-8 to ASCII</li>
</ul>

<p>ASCII to UTF-8 is problematic...<br />
And if I use your UTF-8 to ASCII recoding I would have problems with other chars than cyrillic.</p>

<p>IF you want to create a generic filter (what the name suggests) you should also suport ALL UTF-8 characters.</p>

<p>Until then it would be better to have it named like "Zend_Filter_CyrillicToAscii" and so on.<br />
I am not sure if you are able to support all charsets... how would you recode chinese or japanese chars into ascii ?</p>

<p>I am even not sure if it's a good idea to have chars downgraded, because the meaning can change.<br />
In german for example it's sometimes not the same if you use "ß" or "ss".</p>

<p>Thomas<br />
I18N Team Leader</p>

<p>Please consider including transliteration table for your northern neighbours <ac:emoticon ac:name="wink" /></p>

<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
private function _transliteratePolish ($s)

]]></ac:plain-text-body></ac:macro>

<p>Hi,</p>

<p>here are transliteration rules for Croatian. The same rules are used for Serbian (latin), and Slovenian (although Slovenian language doesn't have character '?' ('?')), and maybe for some other as well.</p>

<p>Some of the characters already exist in other alphabets. </p>

<ac:macro ac:name="code"><ac:parameter ac:name="type">php</ac:parameter><ac:plain-text-body><![CDATA[
/**

• Transliterate Croatian chars
  *
• @param string $s
• @return string
  */
  private function _transliterateCroatian ($s)
  Unknown macro: { $table = array ( '?' => 'C', '?' => 'C', 'Ž' => 'Z', 'Š' => 'S', '?' => 'D', '?' => 'c', '?' => 'c', 'ž' => 'z', 'š' => 's', '?' => 'd', ); return strtr($s, $table); }

public function testCroatian ()

]]></ac:plain-text-body></ac:macro>

<p>There is an interesting post on <a class="external-link" href="http://www.sitepoint.com/blogs/2006/03/03/us-ascii-transliterations-of-unicode-text/">http://www.sitepoint.com/blogs/2006/03/03/us-ascii-transliterations-of-unicode-text/</a> on the subject of transliteration.</p>

<p>My main reason for using this ZF component would be to make sure that titles of the articles are transliterated to URIs so I get valid, and readable URIs.</p>

<p>Did you have a look at the <a class="external-link" href="http://derickrethans.nl/translit.php">http://derickrethans.nl/translit.php</a> library mentioned in the articles comments?</p>

<p>There is a recent (well, a few years recent <ac:emoticon ac:name="wink" />) library for transliteration called UTF8 To ASCII (utf8_to_ascii on Google). It's a simple concept which parses an incoming UTF-8 string, breaks it into UTF-8 characters in hex form, and grabs a sensible hand-picked transliteration from a set of static transliteration tables (just a bunch of PHP arrays). The translit tables are common data (I think Perl has the same set) and the remaining source code, while complex, isn't long. I think it's a really great approach to research and existing data will aid your collection.</p>

<p>I do think Thomas' suggestion is probably not a good one - you should focus only on UTF-8 to ASCII. The reverse is almost impossible unless the UTF-8 to ASCII follows a very specific algorithm (the most common being implemented for IDNs) otherise how could you even tokenise it sensibly? The point afterall is to create sensible, human readable, and agreeable ASCII alternatives for UTF-8 characters for presentation in a URI. If you pardon me for summarising... <ac:emoticon ac:name="wink" /></p>

<p>As for translit/iconv etc. - mixing extensions would lead to significant divergence. No two transliteration strategies are identical which is why I strongly prefer a native solution cross compatible anywhere without needing any specific optional extension unless it's really common.</p>

<ac:macro ac:name="note"><ac:parameter ac:name="title">Zend Comments</ac:parameter><ac:rich-text-body>
<p>It looks really useful to have such functionality in the ZF.<br />
API is also clear.</p>

<p>The problem is implementation which doesn't cover all existing languages. That's not good to provide component which works with some inputs and doesn't work with others.</p>

<p>Covering full Unicode range:</p>
<ul>
<li>needs complete transliteration info;</li>
<li>may cause performance problems;</li>
</ul>

<p>On the other hand <a href="http://pecl.php.net/package/intl">intl PECL extension</a> is based on <a href="http://www.icu-project.org/">ICU library</a> which has very comprehensive transliteration functionality.<br />
Hope this functionality will be included into intl.</p>

<p>So proposal is moved to archived section while we don't have full or essential Unicode range covering and don't have pure PHP implementation performance info.<br />
Or while we don't have intl extension with transliteration functionality included into PHP.</p></ac:rich-text-body></ac:macro>