Drupal assumes mod_rewrite bugs which are not there

I also had issues with some special characters and variables. Sorry, no solution.

I was going to make a bug report of the same thing. Tested it a bit and found some fishy things:

- When translated through L10n client, & and # become %26 and %23, respectively.
- Translation normally through Drupal works fine for these characters.
- & becomes %26amp; and so on, no other means of escaping the ampersand worked either.
- < and > become < and >, these are the only cases I found where the ampersand doesn't change!
- All other special characters that can be found on my keyboard work exactly as they should.

This isn't critical, but definitely a bug.

Could be a duplicate of #218516: Translatable entries not HTML encoded

hass: I think #218516: Translatable entries not HTML encoded is about the display of strings to translate, while this is about & not being possible to be passed through in the POST payload, since it is a special char in the payload, and signifies a new variable. It should be encoded when sent IMHO

> & not being possible to be passed through in the POST payload, since it is a special char in the payload, and signifies a new variable

This sounds like a very logical diagnosis.

Well, diagnosed this problem. Saving & as part of translation of any string does not go through depending on your Apache setup. Drupal.encodeURIComponent tries to be smart and assume that mod_rewrite has a certain bug and thus it encodes & (which was encoded by encodeURIComponent() inside it to %26) to %2526. That is then decoded by PHP to %26 and used as is. So when you try to save a string with & in the translation, you get %26 instead (if your mod_rewrite is not buggy, like this function assumes).

/**
 * Wrapper to address the mod_rewrite url encoding bug
 * (equivalent of drupal_urlencode() in PHP).
 */
Drupal.encodeURIComponent = function (item, uri) {
  uri = uri || location.href;
  item = encodeURIComponent(item).replace(/%2F/g, '/');
  return (uri.indexOf('?q=') != -1) ? item : item.replace(/%26/g, '%2526').replace(/%23/g, '%2523').replace(/\/\//g, '/%252F');
};

There is a better explanation of this phenomenon at http://api.drupal.org/api/function/drupal_urlencode/6

Looks like Drupal assumes certain Apache bugs which are not there anymore. Moving to the Drupal core project.

drupal_urlencode() and Drupal.encodeURIComponent() should only be used for encoding the path part of the URL, i.e. they should not be used for encoding the query string (though this isn't mentioned in the documentation - see #310139: drupal_query_string_encode() should not call drupal_urlencode()).

@c960657: well, system.js uses it to encode a GET parameter value, so if this should not be done, then core is putting forward a pretty broken example:

var url = Drupal.settings.dateTime.lookup +(Drupal.settings.dateTime.lookup.match(/\?q=/) ? "&format=" : "?format=") + Drupal.encodeURIComponent(input.val());

Marking this as a duplicate on that one.