For example, when entering name for new content type in Russian, the Machine name generates only '_'
The correct behavior would be to do transliteration of the name before generating machine name

This can be solved adding js script with transliteration function - for example http://plugins.jquery.com/project/syncTranslit
and change function Drupal.behaviors.machineReadableValue in system.js to use the transliteration.

CommentFileSizeAuthor
#2 transliterate-646466.patch2.89 KBxslim
#1 system-transliterate-646466.patch2.89 KBxslim

Comments

xslim’s picture

xslim commented
StatusFileSize
new system-transliterate-646466.patch2.89 KB

So one of solution I've made is creating function
String.prototype.transliterate
and updating

$(this).val().toLowerCase().replace(searchPattern, settings.replaceToken)
to
$(this).val().toLowerCase().transliterate().replace(searchPattern, settings.replaceToken)

You can see patch in attachment.
Patch transliteration is only for russian and ukrainian language.

xslim’s picture

xslim commented
Status: Active » Needs review
StatusFileSize
new transliterate-646466.patch2.89 KB
xslim’s picture

xslim commented
Priority: Normal » Critical
xslim’s picture

xslim commented
Priority: Critical » Normal
Status: Needs review » Closed (duplicate)

duplicate by this #576180: Make the machine-name generation pluggeable?

Anonymous’s picture

Anonymous (not verified) commented
Status: Closed (duplicate) » Needs review

#2: transliterate-646466.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, transliterate-646466.patch, failed testing.

josevitalsouto’s picture

josevitalsouto
Primary language Portuguese, Brazil
Location RN
commented

The Portuguese (Brazil) have the same problem, also any other language that has accents or special characters.

á, â, à, é, í, ó, ü, ú... is converted to _

pounard’s picture

pounard
Primary language French
commented

The transliteration module exists, such feature should be in core it would solve this problem definitely. I just created the "_v_nement" content type (Événement) and I'm really angry right now because I cannot change it back anymore.

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
commented

That issue forces me to always create content types with their English name first then translate the content type's name. This might not seem so bad but it causes the following mess if your site's default language is not English:

- Create the content type with English name (so that its machine name is correct). Because the site's default language is not English, the created content type has an English name but its language is not English.
- So, on to translating the content type... Click add translation for the English translation of the content type and hit save (no need to translate anything - it's all in English anyways).
- Now that you have the actual English content type with its English machine name, back to changing/translating the source language of the content type.

What a mess of a workflow! :/

xjm’s picture

xjm
she/her
Primary language English
commented

See also: #1065626: Machine name not editable if every character is replaced..

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
commented

The D7 patch in #1065626-33: Machine name not editable if every character is replaced. solves this for me: still no machine name is created when the name field of a content type is in non-Latin characters, but now I can hit the 'edit' link/button and add a machine name as I please. I'd prefer it if there was some transliterated auto-generated name that I could edit if not to my liking, but still this is far better then the workflow I used to follow.

PS: how is this issue different from #1065626: Machine name not editable if every character is replaced. again? ...or #567832: Transliteration in core perhaps?

xjm’s picture

xjm
she/her
Primary language English
commented
Status: Needs work » Closed (duplicate)

Apparently someone requeued the patch for testing randomly when it was previously closed as a duplicate, which set the issue back to NW.