Transliterate accented vowels in machine name strings via JS instead of substituting them with underscores

Looks good to me, this is a much-needed feature for non-English websites.

This should target 8.x and be backported to 7.x if it gets in.

If we want to take the easy approach until we get Transliteration in core, I strongly suggest that we need at least this set of data from Django: https://code.djangoproject.com/browser/django/trunk/django/contrib/admin...

RTBC

oops, I found a bug
after the "ç"; line, that ";" should be removed to concatenate with the "đ" bellow

Mac_Weber, this is assigned to you. You're still around to take care of it?

Just thought I'd pitch in here and apply afeijo's find, HTH.

#9: remove_accents_from_Machine_name_strings._Do_not_substitute_by_underscore-1517024-9.patch queued for re-testing.

Patch re-rolled to apply against 8.x.

Better title.

This issue duplicates #567832: Transliteration in core

The machine name JavaScript behavior has been written in a way that allows modules like Transliteration module to replace only the transliterate method with a custom implementation, which is being discussed in #1436596: Support transliteration of machine names for Transliteration module (not sure whether there is any code already)

In general, I disagree with the solution proposed here, because it privileges certain (Latin) non-English languages over other languages, since the transliteration character set is very limited.

Consequently, the moment we commit this to core, people using different languages will immediately start to whine and complain that the limited transliteration set is not sufficient, and actually possibly even bogus for their particular language, replacing accented characters with inappropriate replacements (transliteration is not as simple as you may think).

In turn, I think this approach here won't fix.

I was waiting for this kind of feedback. Agreed. This will be fixed if transliterate make it in core, otherwise it'll need contrib.

That said I totally sympathize with OP, I'm french and it sucks to have a "_" in a middle of a word.

If this is a dupe of #567832: Transliteration in core then why is it being wontfixed? If the other issue is supposed to solve this too, then I guess it's fine (still the status should be "closed (duplicate)" though). If so, are all related info posted here also mentioned in the other issue (to make sure we don't miss something). If the other issue doesn't address all problems mentioned here though, then we shouldn't close this one. If this one doesn't address similar issues for non-Latin languages, then perhaps the right thing to do is file a separate issue that aims to do so - don't close this one.

I guess what I'm trying to say is:

a) We shouldn't close this one with the excuse that it only fixes things half-way unless we make sure there is an issue filed in order to solve everything.

b) I'm honestly truly lost between these related/duplicate issues and I would really like to know which one to follow in order to better understand how/if this is ever going to be solved and in which version of Drupal. Are we going for a holy-grail-type solution here in order to solve all issues or are we seeking to address each specific problem in their own separate respective issue? ...or do we perhaps intent to provide an API-only solution in core and leave it up to contrib (yet once again)? Which is it?

You're right it's better to say it's a duplicate.

Currently:
- The JS is left for contrib to fix,
- It's possible to override the default JS function by replacing Drupal.behaviors.machineName.transliterate.

I don't think core should be more involved than that since those issues are very tricky.