How do I put this?<\/p>\n
Dear WooThemes<\/a>: to me, you have become one of the references on how to run a successful business, based solely on WordPress. Not only do you offer fantastic, pixel-perfect themes<\/a>, but also excellent plugins, most visible of which are WooCommerce<\/a> and Sensei<\/a>. I’ve used your themes and plugins a few times in the past, and only have good things to say about the structure, performance and robustness of the code. What’s more, and keeping in mind that code quality alone does not a perfect WordPress business make, you truly make a difference in what you contribute to core, sponsor almost every WordCamp in sight, and, most important of all, provide world class customer support.<\/p>\n Which is precisely why some theme-related i18n decisions (or maybe a lack of them) baffle me to no end. Allow me to explain: I was looking for a solid framework upon which I could quickly build a website for a family member (read: unpaid), in a language that’s not English<\/span>. Hold on, this is not where my troubles started; I downloaded my purchased copy of your Canvas theme<\/a>\u00a0(version 5.5.7) to my local installation, fiddled with the CSS and Javascript until the site was just the way I liked it, fixed a few things and the site was ready. I didn’t change, or even look at, a single line of PHP. All that went well and quickly.<\/p>\n The only thing left to do was to translate the theme’s strings to Portuguese. This isn’t a daunting task anymore: by having translated so much of WordPress itself, and also many plugins and themes, my PoEdit<\/a> installation has accumulated a very large translation memory, which normally takes care of a significant amount of the work.<\/p>\n And so, trouble began…<\/p>\n The first surprise is that there is no .pot file \u2014 Seriously? What’s with all you people<\/a>? Is it the file extension that scares you off? Let me, if I may, give you a very quick reminder of language file formats<\/a>: we have<\/p>\n So the first fix you’d have to implement is to actually supply a proper .POT file with every single theme, named after the theme’s slug<\/strong>, like so: I did run Why, oh why, do all your themes load the same ‘woothemes’ textdomain? I understand that there is nothing formally wrong with this, but you could run the risk of seeing mixups in loaded translations. Here’s what the Theme Developers Handbook<\/a> has to say about it:<\/p>\n You need to use a text domain to denote all text belonging to that theme. The text domain is a unique identifier, which makes sure WordPress can distinguish between all loaded translations. This increases portability and plays better with already existing WordPress tools. The text domain must match the slug of the theme. If your theme\u2019s name My Theme is defined in the style.css or it is contained in a folder called my-theme the domain name should be my-theme. The text domain name must use dashes and not underscores.<\/p><\/blockquote>\n So, the second fix would be to correct the textdomain on every I thought that would be pretty much all, I mean I only needed to check that the call to\u00a0\u00a0.pot is not only legal, but actually mandatory<\/h3>\n
\n
pt_PT.po<\/code> file and translate that (still no “T”, get it?).<\/li>\ngettext<\/code>\u00a0functions actually use (they don’t care about .POT or .PO files), and are a “compiled” version of the .PO file, discussed before. Again, because (surprisingly) it bears repeating, this is the only file WordPress will read when looking for translations<\/span>, nothing else.<\/li>\n<\/ul>\ncanvas.pot<\/code>, in the lang<\/code> folder. You can do this by running makepot.php<\/code> before every code commit to that theme’s repository, see here<\/a> how Mike did it. I’m not even going to address the odd presence of a single, lonely en_GB.po<\/code> file in the \/lang<\/code> folder, for fear of finding out exactly which reasoning led to that…<\/p>\nmakepot.php<\/code> on Canvas, which brings us to the second surprise:<\/p>\n\u00a0The textdomain parameter is not an arbitrary decision<\/h3>\n
gettext<\/code> call<\/strong> (those __()<\/code>‘s and _e()<\/code>‘s and what have you). You know, not\u00a0the_content( __( 'Continue Reading →', 'woothemes' ) );<\/code> but rather\u00a0the_content( __( 'Continue Reading →', 'canvas' ) );<\/code>. Everywhere. Tough, I know.<\/p>\nload_theme_textdomain<\/code>\u00a0was present and needed fixing, and… oh, look, not only is it there, it’s being called twice. What?<\/p>\nLoad ALL the textdomains!<\/h3>\n