Fork plupload library so we can use Drupal native translation tools on it

It doesn't, but we could.

I think justintime wanted to work on this.

AFAIK, this is an acceptable reason to fork a third party javascript library and commit it to d.o.

Please, let's not set unrealistic goals. If you fork the library, are you willing to support the fork ? If not, then why bother ? This is LOTS of work. Don't underestimate it.
It's not that hard to support non-Drupal way of translating.

If it's maintained as a patch then "forking" is not such a bad/unmaintainable thing.

I don't see why you would say what is reasonable or unreasonable for someone else.

Does the Plupload library have a means to do translations itself?

Does the Plupload library have a means to do translations itself?

It is described in the original post. You are supposed to add JS containing the translations object. What's a problem with that ? Besides that, it's even stated in their FAQ, that there are ready to use translation files, available for download. If that doesn't work, then it should be explained why, before suggesting forks, right ?
If someone wants to use Drupal translation mechanics, isn't it more logical to create bridge solution that creates the translation object using Drupal translations database, rather than to fork the library ?
I see lots of solutions, and forking is the worst.

I have a suggestion: Make an in-module callback for plupload/%language_code/i18n.js that outputs javascript (through PHP) after running the strings through t().

Then just:

drupal_add_js(url('plupload/' . $GLOBALS['language_content']->language . '/i18n.js', array('external' => TRUE));

Plus you only have to add the menu callback and Javascript if module_exists('locale')

The only downside to this is we don't get proper plural localization with strings like '%d files queued'.

Now that I think about it, there's no reason for this to be in PHP either - we can just have a plupload.i18n.js file that runs Drupal.t() on the strings, but this also allows us to do this server-side.

See #1270632: Use Drupal translation system for a D6 version where approach similar to #8 is implemented.

I've recreated the patch from #6. Now the translations are working correctly :)

I was testing this solution and I think that there are some problems when JS aggregation is used. It looks like Drupal does not include this in agreggated files, so this JS code is missing.

I'd rather go with a actual .js file for that reason.

Patch follows....

Patch attached.

Patch attached.

Patch really attached.

Does not work for me!

File is included but returned object is not translated! Tested by writing "plupload.addI18n()" into console. (Chrome 16)

Manual test with "Drupal.t('Filename');" returns the correctly translated string. Something is going wrong :-/

Also cleared browser and drupal cache... did not help

It looks like this file needs to be included in footer, as translation info is not loaded early enough.

Attached patch works for me. Please check.

Working for me :) RTBC

Commited to 7.x-1.x: http://drupalcode.org/project/plupload.git/commit/da6e4bf

Thanks!

Thank you all! You saved my day!

It does not work for me.

I do not see the js attached to the footer.

The locale module is active...

It should work. Are you really using latest version of Plupload? Tried to clear caches?

I'm sorry if this sounds like a stupid question but still i don't get the right procedure to make translations work.
I installed the dev release and i see plupload library contains all the translations needed inside his js/i18n folder. Should i move those files somewhere else inside the module? because right now are not loaded at all.
Thanks
Michele

Do you have locale.module enabled? Have you tried to clear cache?

Add a question