A subject finally getting some attention in the WordPress community is i18n, or internationalization.

Internationalization is the process of making an application ready for translation. Often this gets confused with localization, which is the process by which the text on the page and other settings are translated and adapted to another language and culture.

Both internationalization and localization are equally important within WordPress, but there cannot be any localization if the theme or plugin has not been internationalized first. Therefore it is of utmost importance for WordPress theme and plugin developers to internationalize their software, regardless of whether it ever actually receives a translation into another language.

In the past couple of months we have seen more and more articles being published on the subject of internationalization. Some are even dripping with frustration!

• Last October Thord Daniel Hedengren published Don’t Be A Dick: Localize Everything, then
• in December David Decker posted The 7 Cardinal Sins of Localizing WordPress Plugins and Themes.

I must admit that I have left frustrated comments on sites like WPCandy, WPBeginner, WPMU and the like, whenever something is promoted that is not properly internationalized. It seems I finally got someone’s attention as Ryan is the one who asked me to write this editorial after I left yet another frustrated comment on one of the articles published here.

For those whose native language is not English and who want to develop websites in more than one language, it is very frustrating to read any news about Fantastic Hypothetical Theme A or Cool Plugin B that were just released, only to realize after downloading that it is actually completely useless since it hasn’t be internationalized!

And do you know what is even worse? When said theme or plugin costs money (often called premium). Not only is that frustrating, it’s just wrong. Despite the number of features your theme or plugin has, if it has not been internationalized it shouldn’t be sold in the first place.

This is just not open for discussion. Internationalization should be common practice, not a feature!

But then again…

It actually is not that strange that for many developers internationalization comes as an afterthought. If you look at the Theme Development Standards article in the WordPress Codex, you will see that all the way down, somewhere at the bottom is a quick note about internationalization:

To ensure smooth transition for language localization, use the gettext functions for wrapping all translatable text within the template files. This makes it easier for the translation files to hook in and translate the titles into the site’s language.

“This makes it easier”? Without it, the theme is impossible to translate! Anyone interested in this part of the standards will need to do lots of additional reading.

I believe that because WordPress is primarily an American invention and most popular blogs that cover WordPress are put together by people that reside in the USA, one can unfortunately safely assume that internationalization is not high on anybody’s priority list.

After all, English is the primary language in use on the web, right?

In reality it’s not. The world is larger than the North America. As a matter of fact, as of December 2011 English is being used by only 27% of (online) users worldwide; that is a bit more than one-quarter of the total internet population (via Wikipedia).

I ask you to briefly consider the following: If you are a premium theme developer who properly internationalized your themes, your potential market would instantly increase by four times.

That convinced you, now didn’t it?

Implementation tips

The best part is that internationalizing your themes is actually quite easy.

First, I would suggest you add the textdomain to your theme and to set up a special directory for additional languages. For this to work you need to add the following lines to your functions.php file:

add_action('after_setup_theme', 'my_theme_setup'); 

function my_theme_setup() { 
	load_theme_textdomain('mytheme', get_template_directory() . '/languages');
}

On line 4 you see mytheme. This is going to be your textdomain and you will need to replace this with the name of your theme. If your theme name is very long, you can also use something shorter. Make sure that it is unique.

If you are using a child theme you should replace load_theme_textdomain with load_child_theme_textdomain.

If you would actually also localize your WordPress theme and offer it with a few additional languages on launch, you would add the .mo files of these languages to the languages directory.

After setting up the textdomain, next is the actual internationalization of the strings in your theme.

First up is displaying translated text. Let’s have a look at the theme Sunny Blue Sky, which is one of the most recent themes (at time of writing) added to the WordPress Theme Directory.
Via the theme SVN we can have a peek at the theme’s files and we hit the jackpot at the first available file: the 404.php:

<h1 class="content-title">Error 404 - Not Found</h1>

<p>Apologies, but the page you requested could not be found.</p>

The correct way of writing these strings is:

<h1 class="content-title"><?php _e('Error 404 - Not Found', 'sunny-blue-sky'); ?></h1> 

<p><?php _e('Apologies, but the page you requested could not be found.', 'sunny-blue-sky'); ?></p>

That wasn’t so hard, now was it?

Next up is processing the translated text. To show this I use a string in the functions.php file:

<?php

add_action('widgets_init', 'SunnyBlueSky_sidebar');

function SunnyBlueSky_sidebar() { 
	register_sidebar ( 
		array ( 
			'name' => 'Sidebar Widget Area', 
			'id' => 'sidebar-widget-area', 
			'description' => 'The sidebar widget area', 
			'before_widget' => '<li>', 
			'after_widget' => '</li>', 
			'before_title' => '<h2>', 
			'after_title' => '</h2>', 
		)
	); 

} 

To internationalize this, we change the strings as follows:

<?php 

add_action('widgets_init', 'SunnyBlueSky_sidebar');

function SunnyBlueSky_sidebar() { 

	register_sidebar ( 
		array ( 
			'name' => __('Sidebar Widget Area', 'sunny-blue-sky'), 
			'id' => 'sidebar-widget-area', 
			'description' => __('The sidebar widget area', 'sunny-blue-sky'), 
			'before_widget' => '<li>', 
			'after_widget' => '</li>', 
			'before_title' => '<h2>', 
			'after_title' => '</h2>', 
		)
	);

} 

Also not super tough, right?

It does actually get a bit more complicated than this as there are more possibilities to write strings; without getting into too much details – after all this information is widely available online – I will list the most common ones below:

<?php 

printf( __('We deleted %d spam messages.', 'mytheme-textdomain'), $count);

<?php 

printf( __('Your city is %1$s, and your zip code is %2$s.', 'mytheme- textdomain'), $city, $zipcode);

<?php 

sprintf( _n( '%s comment approved', '%s comments approved', $approved, 'mytheme-textdomain' ), $approved);

The WordPress Codex has a great tutorial with basically all the options available. The textdomain is all the way at the bottom, so please keep that in mind.

Remember that after you have done it once, the second time will be easier, and the third time even easier than that, and so forth. Furthermore there is plenty of information available online and there are people who can help you with it too (for instance the WordPress forums).

Once you have fully internationalized your theme, you will need to make a .pot or .po file, so translators can do their work and add .mo files per translation. You can include this default .po file by adding it to your languages directory.

POEdit is a handy tool that you can use to generate .pot, .po and .mo files of your internationalized theme or plugin. Smashing Magazine published an article on the subject not too long ago, so I’d suggest referring to that.

Additional resources

If you’re looking for additional reading on this topic, I recommend:

• Tutsplus
• Viper007bond
• WP Engineer

The first issue of The WPCandy Quarterly is in the printing queue as you read these words. Exciting, right? Since there’s nothing I can do to speed up the process (believe me, I would if I could) I’ve taken some time and looked back over the first issue’s development.

One thing I did, while the design process of the Quarterly moved along, was save several drafts. There were nearly 50 individual design drafts of this issue, actually (we drafted articles separately with the individual authors).

Since the drafts were interesting, I put together a quick video showing a few stages of development for various pages within the Quarterly. In the video you get to see the pages when they weren’t much more than words on a page, when they changed formats and styles, and then what they eventually become. I had fun making it, so I hope you enjoy watching it.

I’ve embedded the video below, just after the jump.

Click here to view the embedded video.

The video’s on YouTube and Vimeo. Thanks to 37signals for the inspiration for the general style.

I find it is useful to look back on early versions and first drafts to see exactly how much the magazine progressed. There were times, particularly on a large project like the Quarterly, where I needed inspiration to keep working on it. Peering back at the early versions and seeing how far it had come definitely helped keep me moving at times.

If you haven’t seen the proof or teaser photos yet, check them out.

What is The WPCandy Quarterly?

The Quarterly is a printed publication (yup, the real kind where you hold paper in your hands) featuring articles written by members of the WordPress community. The first issue includes 11 contributors writing about everything from theme frameworks and open source in the government to the ethos of the WordPress community itself. If you enjoy WPCandy at all (or even just a little bit) then this magazine is just for you.

If you haven’t picked up a copy of The WPCandy Quarterly yet, now is the time. Issues will be hot off the printer and shipped out in just a few days!

The 15^th of January through the 22^nd finally saw its first WP on Tour go live. WPCandy mentioned WP on Tour here before, but it’s basically a bunch of WordPress developers (of all shapes and sizes) sharing a working space for a week.  This first edition saw 10 of us — yes, I was fortunate to be among them — in a beautiful house in Sitges, Spain having fun and co-working for 7 days.

You can find the full list of WP on Tour attendees on this Twitter list, You might have noticed some of your WordPress buddies on Twitter mentioning the #wpontour hashtag and you might have concluded that we had a lot of fun…

…and you’d be right! The only thing we really had in common was our love for WordPress, but if you’ve ever been to a WordCamp you know that there are some awesome people out there in the WordPress community. And to an extend, that’s how WP on Tour felt to me. We had a lot of fun getting to know each other, our housepet Wolfy and of course learning from each other as well.

As we were close to Barcelona we of course went all touristy as well and visited the great city.  While in Barcelona we met up with Automattic’s Renewal team, who were in Barcelona at the same time, for even more WordPress geekyness.

Projects launched

The week was not just fun and play (and some clients projects actually needed finishing), but there also was time to share ideas on various personal projects and some of them actually saw the light of day. Briefly, folks worked on the following projects:

• Noel Tock created his version of WordPress meets Stripe: WP Stripe
• Bas van der Lans made a large update to his YouTube DJ tool

The idea behind WP on Tour is to step out of our daily (office) environment and work at a challenging location somewhere in the world. Like a holiday, but with WordPress geeks. This is the best way I know of to get in touch and hang out with developers, designers and evangelists next to visiting a WordCamp. If you feel like organizing your version of WP on Tour then all you’ve got to do is contact Karim.

(Feel like checking out all the pictures we took and what the wolf is doing in some of those pictures? Do check out WP on Tour Flickr pool then!)

The WPCandy Quarterly is, as far as I know, the first-ever WordPress-centric magazine. Or rather, it will be when it begins shipping out to subscribers in the next week or so. On Friday I received the final print proofs, which wraps up the last necessary step before all the issue are printed and delivered.

I’ve dropped in a few photos of the proof sheets below. Of course I’m a bit biased, but I think this issue looks fantastic. I’ll have more to share about the production process next week, but I just couldn’t help sharing this update now. I’m pretty excited to see this coming together.

Remember, we have a limited number of issues. Pick one up today to be sure you have one of the first issues of the Quarterly.

Proof sheets

When magazines like this are produced, a number of pages are printed on one large sheet. The sheets are then cut down to the various spreads and folded into place.

Print vs. digital

Everyone who orders an issue will receive access to digital copies as well, but even so I think the printed version of the magazine is just cool. For this first run we have only 2,000 copies available — if you haven’t picked up a copy of The WPCandy Quarterly yet, now is the time.

You should listen to it, especially if you’re a plugin developer.

If you would rather download it directly you can do that too, or subscribe to this show via RSS or on iTunes. If you would prefer a written summary, you can also read that just after the jump.

Deactivating and uninstalling a plugin are not the same thing

Let’s talk about plugin options. Specifically, what I expect as a user when I deactivate a plugin, versus uninstall one. WordPress has some hooks built in that help enable plugin others to do things, namely register_activation_hook, register_deactivation_hook, and register_uninstall_hook. The deactivation hook and uninstall hook are great places to trigger certain things. Unfortunately, too many plugin authors unset options in the wrong one.

When I deactivate a plugin, I’m not really trying to totally remove the plugin from my site, but rather just turn it off. So when a plugin author deletes all of the options I’ve selected on a plugins’ settings screen on the deactivation hook, it makes me angry that I have to go and reset them when I turn it back on. So angry that I might just find another solution for what your plugin is doing.

What they should be doing instead, is removing these options, and everything else, with the uninstall hook. When i uninstall a plugin completely, it is safe to assume I am finished with it, and it is the appropriate place to take such action. But when I simply deactivate, in all likelihood I’m just debugging something in my theme or another plugin, or maybe backing up or upgrading something.

So consider this a friendly message to plugin developers, and future plugin developers – remove options on the uninstall hook, and not the deactivation hook.

In this episode of Pressbits I discuss the hesitance I sometimes see in folks to release their code as WordPress plugins. Listen, I dare you:

If you would rather download it directly you can do that too, or subscribe to this show via RSS or on iTunes. If you would prefer a transcript, you can also read that just after the jump.

Mine your work for plugins that you can release

Sometimes I get the sense that someone is shying away from releasing any of their work as a plugin. They will say things like “this isn’t that complex” or “this isn’t worthwhile or unique”. But the thing is, we (the community) need more plugins that are small, simple, and compact.

Dig into your functions file, your functionality plugins, or even stray code that you have within your theme files. Be watchful for what could become a general public plugin. If not for your own sake — some aren’t interested in maintaining plugins on WordPress.org, which I get — then release them for me. I want to see your awesome ideas, the ways you have solved your own problems, and whether they might be useful for myself or others. Some of my favorite plugins are not big and powerful, but small and very specific.

One thing I’ve learned by being a part of the WordPress community (or is it communities?) is that code you keep to yourself can end up stale and weak. Sharing code, on the other hand, using WordPress.org or Github (my two favorites) means that others can add to and improve on your code. It also helps to bring you further into the community and makes others aware of you and your ideas.

Personally I try to turn as many of my site’s features into plugins as possible (internally). They instantly become easier to manage and seem generally more organized than as scattered functions in a file or two. Now I just need to take my own advice and release a slew of my own tiny, purpose-specific plugins.

Are you sitting on any code (read: solutions to problems) that you could take a few minutes to release as a plugin?

This morning Collis Ta’eed announced on the Envato Notes blog that their price adjustment tool, previously available to Envato Elite authors on their marketplaces that reached $75,000 in sales, is no longer available. Normally prices on the Envato marketplaces are set by Envato during the product review process, and not by the author of the product. The price adjustment tool, announced last year, allowed certain authors to test out different prices for their products beyond what the marketplace would set for them.

The change, Ta’eed said, comes to prepare for the next major change to Envato’s pricing strategy. The introduction of variable pricing for certain elite authors was Envato’s first step toward dynamic pricing. “While it has had some success,” he said, “it’s become clear to us that it’s not the long-term solution.” The updated pricing solution — while what it is isn’t exactly clear yet — is slated for release “later this year”.

With the pricing tool removed, any marketplace products with modified prices will be left at the last price their author left them at. This affects 160 current authors who have already reached the $75,000 Elite level.

As a replacement for the price adjustment ability, which was the main draw at the $75,000 Envato Elite level, authors will be given an Elite badge on their products and the ability to give themselves a custom forum title. Each author will also 12 months of Envato’s Tuts+ Premium membership.

Ta’eed recognized in his post that this news could disappoint authors. He said:

In the meantime I wanted to give a personal apology for the inconvenience of not having access to the price adjustment tool. I know many existing and new Elite authors were warming up to the tool and increasingly using it. And I realize that in those cases, our new additions will likely not make up for the removal.

Responses to the announcement in the ThemeForest forum are mixed, though some are disappointed at the change and, sometimes, lack of communication. Orman Clark, who has quite a sales record on ThemeForest, responded in disappointment at the news:

As someone that operates their entire business through ThemeForest, and has managed to grow a small team around it, substituting one for the other is not going to wash. And while everyone can always learn something new, 12 months access to Tuts+ is hardly a worthy replacement or incentive based on the assumption that Elite authors have already got some skills to pay the bills.

Ta’eed did join the discussion in that forum thread, answering questions and responding to suggestions. It’s an interesting discussion if you’re interested in some of the dynamics and thought process behind the largest WordPress theme marketplace in the world.

In this, episode 30 of the WPCandy Podcast, we officially adopt a new format for the official show. In short, the goal is for the WPCandy Podcast to deliver a higher awesome per minute ratio, and be the “if you only listen to one WordPress podcast, listen to this one” podcast.

But that’s not all. In this episode Brian and I recap on 2011 at WPCandy, and I sit down to interview Andy Skelton and Joen Asmussen from Automattic about the WordPress.com/Jetpack year-end reports (example).

You can listen to the podcast here:

This week’s episode is just over 41 minutes long. If you want to jump ahead:

• 00:50 Ryan and Brian reminisce on 2011
• 14:55 Interview with Andy Skelton and Joen Asmussen

Subscribe to the show on iTunes, or directly to the RSS feed. As always you can send any emails you would like to have included on the show to podcast@wpcandy.com. The download link is just after the jump.

If you would like to download the podcast in MP3 format directly, you can do so here.

E-commerce is becoming more of a hot topic within the WordPress community. Given this realization, we’ve seen plugins like WooCommerce be released free of charge, among other great e-commerce plugins.

Envato, the company behind ThemeForest and CodeCanyon (just to name of a few of their properties), put up a bounty to plugin developers. They see a need for more e-commerce plugins to be available in their marketplace and they’re willing to pay to get those plugins up there.

Here are the details about the bounty.

• Date Posted: January 11, 2012
• Prizes: 20 winning files will get a share of $2,000 of prizes! 20 x $100 “cash” (payable via either PayPal or Moneybookers).
• Maximum Prizes per Author: 3
• Closing Date: February 11, 2012
• Files We’re Looking For: WordPress e-Commerce Plugins built for the following plugins:
• WP e-Commerce
• WooCommerce
• Jigoshop
• Cart66
• An item created and converted to another sub category is allowed! So for example, a Cart66 plugin converted to Jigoshop and WooCommerce has the potential to win $300 (presuming they are all one of the first 20 items submitted/approved of course).
• “Standalone” and “Other” plugins are NOT eligible for this contest.
• Envato Staff are NOT allowed to enter Envato’s Most Wanted. Volunteer Community Moderators ARE allowed to participate.
• Where Files Should be Submitted: http://codecanyon.net/category/plugins/wordpress/e-commerce within the appropriate sub category.

You still have another week to get your plugins in and capture up to $300 of that bounty.