Textdomain as plugin slug

[NateWr]

First, thanks for this. I've been using my own grunt-init template for a while and really happy to be able to compare notes and pull in some more tricks for my own.

I noticed that you don't use the plugin slug/filename as the textdomain. Otto has mentioned changes that are coming to the WordPress.org plugin/theme repositories to handle translation management, which would require the textdomain match the plugin slug. I made the mistake of not doing this so I will have to switch and manage backwards compatibility.

I raise this issue to a) let you know it might be worth updating this or b) benefit from hearing why not from people smarter than myself.

(ps - if anyone knows of a plugin that's switched textdomains and maintained backwards compatibility, I'd love a link!)

[johnpbloch]

I can't really give a reason for the original decision nor will I comment on what this project will be doing going forward. I can give you advice on back-compat, though.

Internally to your plugin, you don't need to maintain any backwards compatibility. Change the textdomain in all places it's used and rename all .pot, .po., and .mo files to use the new textdomain instead of the old one. Where you will need back-compat is if they have a custom translation of your plugin installed in their language directory for a language you don't support. To maintain back-compat there, you would do something like this:

<?php

add_filter( 'load_textdomain_mofile', function( $mofile, $domain ) {
  if (
    'your-textdomain' === $domain &&
    0 === strpos( $mofile, WP_LANG_DIR . '/plugins/' &&
    ! file_exists( $mofile )
  ) ) {
    $mofile = dirname( $mofile ) . DIRECTORY_SEPARATOR . str_replace( $domain, 'your-old-textdomain', basename( $mofile ) );
  }
  return $mofile
}, 10, 2 );

What that does:

• Adds a filter on the location of the mofile
• Makes sure it's a lookup for your plugin
• Makes sure it's not a lookup for a mofile distributed with your plugin
• Makes sure the user hasn't already changed the slug of their custom translation
• Swaps the old textdomain in place of the new one

And, of course, if you want to be compatible with PHP 5.2, change the closure to a named function.

Hope that helps!

[NateWr]

Wow, you did my work for me! Amazing.

[ericmann]

In the beginning, the only requirement was that a unique textdomain be used. Otto's blog aside, this is the first I've heard of the plugin slug being used as a textdomain. Completely open to making that change.

[ericmann]

Closing for now as the plugin slug change hasn't amounted to anything yet ...