How to translate a WordPress template name?

2 comments

1. I stumbled upon that quite recently. Here is how I got around this:

   First, add(if you already don’t have that) Text Domain: mytext_domain to your style.css, where mytext_domain is the actual text domain for your theme.

   Then add a dummy call to the translating function somewhere in your theme(best thing is to add it just under the Template Name declaration, so you don’t wonder why you’ve put it):

   /**
    * Template Name: Three columns
    *
    * @package WordPress
    */
   __( 'Three columns', 'mytext_domain' );
   

   The reason to do this is because WordPress passes your template name to the translate() function, but since translator plugins parse your code, they are not aware that your template name should be part of the .po(or was it .mo?) file. The dummy call to __() fixes that issue.

   And the reason why you add Text Domain declaration to your style.css is because this is where WordPress looks for your theme’s textdomain when it’s parsing template names.

   I can’t give you exact sources, since I really just poked around the core code, until I figured-out how it works and how to be able to translate my template names.

   PP: I’m not sure how Poedit works – if you add your translations by hand, you might not need the dummy call – just test with and without it and use whichever fits you best 🙂

   Log in to Reply

2. Better method:

   1. Add the Text Domain: theme-slug header to your style.css file, if you have not done so already.

   2. Get a checkout of the official WordPress developer package by checking out the develop.svn trunk: http://develop.svn.wordpress.org/trunk/

   3. In there, you will find a directory called /tools/i18n. In that directory is a makepot.php file. You can use it for themes as follows:

   > php makepot.php wp-theme /path/to/your/theme/directory theme-slug.pot

   This will create the POT file for you, using the latest WordPress code. It gets the strings from headers, from all of the WordPress i18n functions, everything. It also means that you don’t need to create any “fake” strings like the other answer suggests.

   Make sure you do an svn update every once in a while too, as the i18n tools and the core trunk code can be updated for new things every once in a while.

   Note that when using the i18n tools, they need to be in the trunk checkout. You can’t move them around in the filesystem, because they depend on WordPress functions to do some of the parsing of the files, so they have relative include paths back up the tree into the WordPress core /src directory. The trunk directory as-a-whole needs to be intact for the tools to work properly. However, the trunk directory can be unconfigured, you don’t need to have a working installation of WordPress, it just needs some of the WordPress code to do the parsing of the files properly.

   Log in to Reply