Posted by kouri on July 15, 2011 at 2:58pm
8 followers
| Project: | Plupload integration |
| Version: | 7.x-1.x-dev |
| Component: | Documentation |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Plupload site explains how to translate plupload lib (http://www.plupload.com/punbb/viewtopic.php?pid=3949)
1) create an internationalization i18n js file (or grab an already existing one)
2) place it with all plupload js files under /js folder
3) into the caller html file, declare this i18n file just after the plupload.js declararation
Is this procedure still possible in Drupal ?
Which file must be changed to load the the translation file ?
Comments
#1
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.
#2
Thx for the answer.
So I understand that, actually, there's no choice but directly patch plupload .js files
Am I right ?
#3
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.
#4
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?
#5
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.
#6
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:
<?phpdrupal_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')
#7
#8
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.
#9
See #1270632: Use Drupal translation system for a D6 version where approach similar to #8 is implemented.
#10
I've recreated the patch from #6. Now the translations are working correctly :)
#11
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....
#12
Patch attached.
#13
Patch attached.
#14
Patch really attached.
#15
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
#16
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.
#17
Working for me :) RTBC
#18
Commited to 7.x-1.x: http://drupalcode.org/project/plupload.git/commit/da6e4bf
Thanks!
#19
Automatically closed -- issue fixed for 2 weeks with no activity.
#20
Thank you all! You saved my day!