Answers.Body: <p>Yeah, this is an issue we're aware of of the 2.x branch that's been resolved for Craft 3.x and we probably won't back-port because of the complexity involved.</p>
  
  <p>But in 2.x, we naively assumed that there was going to be a 1:1 mapping between the character that needed to be replaced and it's replacement.</p>
  
  <p>Turns out that is by no means the case.</p>
  
  <p>So for Craft 3, we're using the <a href="https://github.com/danielstjules/Stringy" rel="nofollow">Stringy</a> library and you <a href="https://github.com/danielstjules/Stringy/blob/master/src/Stringy.php#L487" rel="nofollow">can see</a> they have a 1:many mapping and the <code>š</code> character properly maps over to <code>s</code>.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-13T14:27:51.603Z
Answers.Text: Cyrillic characters with `limitAutoSlugsToAscii` set to `true` in Craft 2.x don't get converted at all, neither in slugs or in filenames (with `convertFilenamesToAscii` set to `true`). So with the first option turned on we get an empty slug saved for the first entry after changing config and `URI "" has already been taken.` message for the all following entries (and this makes it impossible to save them at all).
  `
Answers.UserDisplayName: certainlyakey
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-13T14:37:48.207Z
Answers.Text: Any values included in `customAsciiCharMappings` do not affect this behaviour, whether they are Cyrillic (`'ж' => 'zh'`) or Latin (`'F' => 'ph'`).
Answers.UserDisplayName: certainlyakey
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-09T15:33:32.463Z
Answers.LastActivityDate: 2015-04-09T15:33:32.463Z
Answers.UserDisplayName: Brad Bell
Answers.Body: <p>You can try using my plugin, which will overwrite the character map in craft.js by applying the customAsciiCharMappings setting:</p>
  
  <p><a href="https://github.com/farmstudio/slugcharmap" rel="nofollow">https://github.com/farmstudio/slugcharmap</a></p>
  
  <p>Tell me if it's working for you.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-26T13:32:18.103Z
Answers.LastActivityDate: 2015-11-26T13:32:18.103Z
Answers.UserDisplayName: drifteaur
Answers.Body: <blockquote>
    <p>In Czech language that is not necessary; it's rather <strong>bad behavior</strong> which I need to change.</p>
  </blockquote>
  
  <p>If this is true, you should email the issue to P&amp;T and I'm sure they will update the mapping table for the next release.</p>
  
  <p><strong>Update:</strong> I don't think there's a (good) workaround, the table is hardcoded into craft.js and the function that generates the slugs only got the option to disable the character replacement completely. You could disable it and try to add your own JS that replicated the functionality with a custom plugin, this might work. But I actually think you should report that issue to P&amp;T and they will probably come up with a solution to make all Czech happy without the need for any plugin.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-09T08:13:06.393Z
Answers.Text: it might be desired behavior in other languages, so updating the mapping table for Czech language might break some other languages.
  I will report a feature request to configure mapping table on-fly, but first I'd like to be sure there is no workaround or recommended procedure to already achieve that.
  I haven't found any, but I am new to Craft, so I might be missing something
Answers.UserDisplayName: Jan Klan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-09T09:16:03.590Z
Answers.Text: Ahh now I get it, so this actually needs to be language dependant what it isn't right now.
Answers.UserDisplayName: carlcs
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-10T10:09:23.693Z
Answers.Text: That's exactly the problem.
Answers.UserDisplayName: Jan Klan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-09T07:38:35.553Z
Answers.LastActivityDate: 2015-04-09T09:28:19.750Z
Answers.LastEditDate: 2015-04-09T09:28:19.750Z
Answers.UserDisplayName: carlcs
Body: <p>I've been struggling with automatic slug generation in Czech language: there are letters such as "š" or "č" and Craft has a charactere map hardcoded in craft/app/resources/js/craft.js, resp. craft/app/resources/js/compressed/craft.js, which tells craft to convert "š" to "sh" and "č" to "zh" for instance. </p>
  
  <p>In Czech language that is not necessary; it's rather bad behavior which I need to change. Letter "š" should become "s" etc. </p>
  
  <p>Is there any systematic way how to configure this character map? </p>
  
  <p>I technically have no problems with rewriting the table, although that solution might either cause errors with automatic updates or my changes could get rolled back with every update - neither being good. </p>
  
  <p>PS: This issue is NOT related to the same thing as here: <a href="https://craftcms.stackexchange.com/questions/2660/how-to-transform-german-umlauts-when-creating-slugs">How to transform German umlauts when creating slugs?</a> - the described behavior is in place even with "limitAutoSlugsToAscii == 1"</p>
  
  <p><strong>UPDATE:</strong></p>
  
  <p>In case this question was not resolved yet or had no solution, here is a minified charmap which works as a hotfix to Craft issues with Czech slugs: <a href="http://pastebin.com/pc6etBFu" rel="nofollow noreferrer">http://pastebin.com/pc6etBFu</a></p>
  
  <p>It works as a drop-in replacement for the same map in craft/app/resources/js/compressed/craft.js. My current version of craft is Craft Pro 2.3.2643</p>
  
Tags: <slug>
Title: Trouble with transliteration in slug caused by hardcoded charmap in craft.js
ThreadText: # Trouble with transliteration in slug caused by hardcoded charmap in craft.js
  
  (Asked by: username_0 on 2015-04-09)
  
  I've been struggling with automatic slug generation in Czech language: there are letters such as "š" or "č" and Craft has a charactere map hardcoded in craft/app/resources/js/craft.js, resp. craft/app/resources/js/compressed/craft.js, which tells craft to convert "š" to "sh" and "č" to "zh" for instance.
  
  In Czech language that is not necessary; it's rather bad behavior which I need to change. Letter "š" should become "s" etc.
  
  Is there any systematic way how to configure this character map?
  
  I technically have no problems with rewriting the table, although that solution might either cause errors with automatic updates or my changes could get rolled back with every update - neither being good.
  
  PS: This issue is NOT related to the same thing as here: [How to transform German umlauts when creating slugs?](https://craftcms.stackexchange.com/questions/2660/how-to-transform-german-umlauts-when-creating-slugs) - the described behavior is in place even with "limitAutoSlugsToAscii == 1"
  
  **UPDATE:**
  
  In case this question was not resolved yet or had no solution, here is a minified charmap which works as a hotfix to Craft issues with Czech slugs: <http://pastebin.com/pc6etBFu>
  
  It works as a drop-in replacement for the same map in craft/app/resources/js/compressed/craft.js. My current version of craft is Craft Pro 2.3.2643
  
  **Tags:** slug
  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_1 on 2015-04-09. Score: 2 | Accepted answer
  
  Yeah, this is an issue we're aware of of the 2.x branch that's been resolved for Craft 3.x and we probably won't back-port because of the complexity involved.
  
  But in 2.x, we naively assumed that there was going to be a 1:1 mapping between the character that needed to be replaced and it's replacement.
  
  Turns out that is by no means the case.
  
  So for Craft 3, we're using the [Stringy](https://github.com/danielstjules/Stringy) library and you [can see](https://github.com/danielstjules/Stringy/blob/master/src/Stringy.php#L487) they have a 1:many mapping and the `š` character properly maps over to `s`.
  
  > **Comments:**
  > **username_2**: Cyrillic characters with `limitAutoSlugsToAscii` set to `true` in Craft 2.x don't get converted at all, neither in slugs or in filenames (with `convertFilenamesToAscii` set to `true`). So with the first option turned on we get an empty slug saved for the first entry after changing config and `URI "" has already been taken.` message for the all following entries (and this makes it impossible to save them at all). `  
  > **username_2**: Any values included in `customAsciiCharMappings` do not affect this behaviour, whether they are Cyrillic (`'ж' => 'zh'`) or Latin (`'F' => 'ph'`).  
  
  ---
  
  ### Answer by username_3 on 2015-11-26. Score: 3
  
  You can try using my plugin, which will overwrite the character map in craft.js by applying the customAsciiCharMappings setting:
  
  <https://github.com/farmstudio/slugcharmap>
  
  Tell me if it's working for you.
  
  
  ---
  
  ### Answer by username_4 on 2015-04-09. Score: 1
  
  > In Czech language that is not necessary; it's rather **bad behavior** which I need to change.
  
  If this is true, you should email the issue to P&T and I'm sure they will update the mapping table for the next release.
  
  **Update:** I don't think there's a (good) workaround, the table is hardcoded into craft.js and the function that generates the slugs only got the option to disable the character replacement completely. You could disable it and try to add your own JS that replicated the functionality with a custom plugin, this might work. But I actually think you should report that issue to P&T and they will probably come up with a solution to make all Czech happy without the need for any plugin.
  
  > **Comments:**
  > **username_0**: it might be desired behavior in other languages, so updating the mapping table for Czech language might break some other languages. I will report a feature request to configure mapping table on-fly, but first I'd like to be sure there is no workaround or recommended procedure to already achieve that. I haven't found any, but I am new to Craft, so I might be missing something  
  > **username_4**: Ahh now I get it, so this actually needs to be language dependant what it isn't right now.  
  > **username_0**: That's exactly the problem.  
  
  ---
  
  