Make WordPress Core

Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#5242 closed defect (bug) (worksforme)

upload.php after file upload not L10n'ed (script-loader.php)

Reported by: lybica Owned by:
Milestone: Priority: normal
Severity: minor Version: 2.3
Component: I18N Keywords: l10n, localization, upload, script-loader
Focuses: Cc:


Using SVN /tags/2.3 with ja.mo

After submitting an image file from post editor with upload.php, the next page with "Show: Thumbnail", "Link to: File", etc. is not loading localized strings even though __() is called for each "uploadL10n" entry.

Is seems that .mo file is not effective before

 $this->localize( 'upload', 'uploadL10n', array(

in wp-includes/script-loader.php (line 124-),
because changing $val to __($val) at

 echo "$eol\t\t$var: \"" . js_escape( $val ) . '"';

(line 203) solves the problem.

Change History (4)

#1 @nbachiyski
14 years ago

  • Milestone 2.3.1 deleted
  • Resolution set to worksforme
  • Status changed from new to closed

These are in Bulgarian for me, using vanilla 2.3.

$this->localize(... just constructs an object, containing the translated strings before loading the actual js file. This object is printed, as a javascript object, around line 203.

Probably the ajax calls were cached and you saw first the strings in English, and when you tried again it was fixed.

Can you confirm that on a clean install?

#2 @lybica
14 years ago

You're right.
I tried it with a new install, and localized strings show up just fine.

But my current install (which I upgraded from 2.2.3) still displays English text for that part.

So I have cached the ajax calls somewhere.
How do I flush the cache?
Obviously it's not on browser-side...

#3 @nbachiyski
14 years ago

I meant browser cache, so it should be flushed somewhere from your browser settings.

#4 @lybica
14 years ago

Actually in that case something is wrong with my wp install. Maybe it is a bug after all.
I have completely flushed my browser cache, tried different freshly installed browsers, even tried different machines, which I never used to access my wp to see if the situation persists. It displays English text.
I can assure you that it is not my browser problem.
And if I switch $val and __($val), the result is consistent. $val contains English text when foreach-echo is called, not L10n'ed text.

Probably some residue from 2.2.3? (I followed the official upgrading guide.)

Note: See TracTickets for help on using tickets.