Make WordPress Core

Opened 17 years ago

Closed 17 years ago

#7075 closed task (blessed) (fixed)

Issues with translating plugins

Reported by: msi08's profile msi08 Owned by:
Milestone: 2.6 Priority: normal
Severity: normal Version:
Component: General Keywords: has-patch
Focuses: Cc:

Description

It's not really a ticket to fix something. But there is an issue, I noticed. I'm running WordPress 2.6 (rev 8030) and I wrote some plugins (just for me) and because I'm a native German speaker I created a german translation. Everything worked fine and then I noticed that my plugins are not translated anymore.

I found a way to fix this: I have to use the complete local path starting with "/home/.../wordpress-folder/wp-content/plugins/my-plugin". I'm not unfamiliar with development so I remember my old function to get the path of the plugin. I'm very sure that it always was "wp-content/plugins/my-plugin". But it stopped working at some time. I also noticed that the function "get_template_directory" results the complete local path (again, starting with "/home/my-profile/.../wordpress-folder/..."). btw, I'm using Linux with the Apache server and PHP 5.x.

Something has changed, but I seem to be the only one noticing that. I tested a plugin of another german developer and it did not work. The other guy told me his copy of WP 2.6 is running fine. Actually, it's running different. He told me he loads his plugins and the language file with a path starting with "wp-content" instead of "/home/my-profile/.../wordpress/wp-content".

Is there anyone out there with the same problem as me?

Change History (3)

#1 @DD32
17 years ago

This would've been a change from #6938 i think.

I'm very sure that it always was "wp-content/plugins/my-plugin". But it stopped working at some time.

Hm.. I'm not sure.
I've been using this myself previously:

load_plugin_textdomain('add-from-server', PLUGINDIR . '/' . dirname(plugin_basename(__FILE__)) . '/langs/');

However that no longer works it seems, This does:

load_plugin_textdomain('add-from-server', WP_PLUGIN_DIR . '/' . dirname(plugin_basename(__FILE__)) . '/langs/');

Not sure why this is.. The changes mentioned in the ticket i referenced to does not affect it from what i can see.

As a side note, While testing the languages, i used: define ('WPLANG', 'de'); however, to get the translation to kick in, this time i had to use: define ('WPLANG', 'de_de');, Is that normal and i'm remembering wrong?

#2 @sambauers
17 years ago

  • Keywords has-patch added

There is a bug in that part of the implementation of #6938

The fix for it is here http://trac.wordpress.org/attachment/ticket/6938/load_plugin_textdomain-fix.patch but not yet applied to trunk.

After that fix, the behaviour will be more like before, but not exactly...

If you don't specify the path in load_plugin_textdomain() it will work the same as before.

The difference when you specify the path will be that the path should be relative to WP_PLUGIN_DIR.

So for a plugin located in the standard plugin directory "wp-content/plugins/foo/foo.php" with language files at "wp-content/plugins/foo/lang" and a domain of "foo-domain" you would do this...

load_plugin_textdomain( 'foo-domain', dirname(plugin_basename(__FILE__)) . '/lang' );

Remember, this relies on that patch being applied to trunk.

#3 @sambauers
17 years ago

  • Resolution set to fixed
  • Status changed from new to closed

See [8065]

Usage is now backward compatible and the previous comment here does not apply.

This will now look for the language file relative to ABSPATH just like before:

load_plugin_textdomain( 'foo-domain', PLUGINDIR . '/' . dirname(plugin_basename(__FILE__)) . '/lang' );

To search for a language file relative to WP_PLUGIN_DIR you simply supply a third argument like so:

load_plugin_textdomain( 'foo-domain', false, dirname(plugin_basename(__FILE__)) . '/lang' );
Note: See TracTickets for help on using tickets.