Since we don't, and can't have transliteration in core for D7 I suggest we remove the automatic machine friendly name generation from the new node type creation pages, because it is broken for non-latin languages.

For more info see #567832: Transliteration in core

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

sun’s picture

Title: Remove machine friendly name generation from the node type creation UI » Remove machine-readable name generation from the node type creation UI
Status: Active » Postponed (maintainer needs more info)

That's why there is an "edit" link to alter the auto-generated machine-readable name.

And. For multilingual sites, the best practice is to use English labels/titles anyway, so you can properly localize/translate them -- which means that the machine-readable name can be properly generated via the existing JS.

snufkin’s picture

You assume that a site is used as multilingual by default and I don't think this is true.

With the current setup any non-latin language (russian, chinese, arabic etc) will be forced to correct the machine suggestion (which will be a single underscore). This is a faulty behaviour, and so it should be removed entirely until proper transliteration can be brought into core.

xslim’s picture

Hi!
I posted the same issue - #646466: Machine name generating not correctly for languages other than English
maybe we can make a check in JS file - if transliteration module is present - make AJAX call to it?

Damien Tournoud’s picture

Title: Remove machine-readable name generation from the node type creation UI » Make the machine-name generation pluggeable
Status: Postponed (maintainer needs more info) » Active

@xslim: that's an excellent idea.

sun’s picture

errrr. We're talking JavaScript here. Transliteration module can replace the entire behavior or even the entire .js file.

xslim’s picture

so we need to make a patch to transliteration ?

sun’s picture

Title: Make the machine-name generation pluggeable » Override core's machine name generation
Project: Drupal core » Transliteration
Version: 7.x-dev » 7.x-3.x-dev
Component: node system » Code
Category: bug » feature

Yes.

Damien Tournoud’s picture

Project: Transliteration » Drupal core
Version: 7.x-3.x-dev » 7.x-dev
Component: Code » base system
Category: feature » bug
Priority: Normal » Critical

Erm. No! It's not because it's javascript that we should promote sloppy programming practices. We need to abstract the crappy regexp that is currently in *two places* of Drupal.behaviors.machineReadableValue to a separate function that Transliteration will be able to replace.

And yes, we need to do it before releasing D7.

Damien Tournoud’s picture

Title: Override core's machine name generation » Make the machine-name generation pluggeable
xslim’s picture

We can add additional function like transliterate() which can be overridden by transliteration module?

Damien Tournoud’s picture

Status: Active » Needs review
FileSize
2.12 KB

Here.

mfer’s picture

I like this idea but should the translate function live at Drupal.behaviors.machineReadableValue.attach.transliterate? Or, is another location more appropriate?

sun’s picture

+++ modules/system/system.js
@@ -207,6 +208,11 @@ Drupal.behaviors.machineReadableValue = {
+  transliterate: function(source, settings) {

1) Custom methods should have JSDoc to explain them.

2) Missing space after function.

Powered by Dreditor.

Damien Tournoud’s picture

Fixed the issues raised by sun.

Damien Tournoud’s picture

@mfer: the function is at Drupal.behaviors.machineReadableValue.transliterate(), which makes sense to me.

sun’s picture

Status: Needs review » Reviewed & tested by the community

Thanks!

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Seems like a reasonable improvement. It does not cause Drupal to cease to function, and therefore is not critical.

Committed to HEAD.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.