Hardcoded language in javascript files breaks localization

Thanks for your work on this issue Markus.

The suggested approach is straightforward and has the advantage of integrating with our current localization--i.e, we don't have to write additional files.

I've implemented something comparable in the Javascript Tools package, i.e., dynamic generation of js configuration files to accompany behaviours. We would I suppose add a menu item for each configuration file:

    $items[] = array(
      'path' => 'upload/settings.js',
      'title' => t('uploaddefaults'),
      'access' => user_access('access content'),
      'type' => MENU_CALLBACK,
      'callback' => 'upload_settings'
     );

When adding the file, we would have to test for clean urls:

  drupal_add_js((variable_get('clean_url', '0') ? '' : '?q=') . 'upload/settings.js');

And in the callback, we would include a text/javascript header:

function upload_settings() {
  drupal_set_header('Content-Type: text/javascript');
  // I've left out the new lines at the ends of lines because the filter didn't like them.
  print "lang['upload_progress_message'] = '" . t('Uploading file') . '";'";
  print "lang['upload_error_message'] = '" . t('An error occurred:') . '";'";
  exit();
}

This method would need to do a full Drupal bootstrap et al.

True. Elsewhere (e.g., autocomplete) we encode data needed by js into form elements on the page.Should we think of doing the same here? Or could we have a routine to generate the needed localization files, e.g., upload_lang_es.js for the Spanish localization, saving them as new (static) files?

Upgrading to critical, because this breaks localization. If we do nothing else, we should eliminate the 'Uploading file' string from upload.js for 4.7. That's the one that will be seen by regular users even if there are no errors.

Or we could support static localization files, e.g., upload_fr.js.

* we declare the lang array in drupal.js
* in each js file, all user messages are added to this array
* in drupal_add_js, for each file added we test for the existance of a file matching the current $locale,
adding it after the requested file so that it overrides the declared array items.

global $locale;

$localized_file =  substr($file, 0, strpos($file, '.js')) . $locale . '.js';
if (file_exists($localized_file)) {
  drupal_set_html_head(' ..... ');
}

* optionally, we implement an equivalent to the t() function so we can use, e.g., %error.

Going to make this a normal feature request. It's certainly not a showstopping bug.

Okay, agreed, localization is a feature request and not critical at this point

Still, the upload message is going to be a bit glaring and we should probably deal with it for 4.7.

Here's a minimal patch that makes the message argument to the progress object's setMessage method optional, and removes the message from upload.js. This would remove the only untranslatable string that most users are likely to see, arguably a sufficient 4.7 fix.

Forgot the patch.

Scratch that. I was overlooking the fact that anyone who wants to control display of progress messages can do so through css.

For an upload message, the following should do it:

#uploadprogressbar div.message {
  display: none;
}

Or even, I suppose (for browsers supporting the :before pseudo element):

#uploadprogressbar div.message {
  display: none;
}

#uploadprogressbar div.bar:before {
  content: "[translation of 'uploading file']";
}

So, no, we don't need to patch 4.7 and can focus on putting in place a good 4.8 solution.

We finally have a t() for javascript, in Drupal 6. Huzzah!