Disclaimer: These rules below may or may not contain humor, irony and satire. Go, find out for yourself.
Do NOT internationalize your plugins or themes at all. It costs only time. Time is money. So just leave as is. English is the world language anyways, so why bothering with such rubbish? Your users *will* understand your admin interface and any frontend strings. Developers are good at English by default. And even clients in foreign countries may know developers. Also, any customizations of strings (via language files) are not needed as your mantra should always be: decisions not options, stupid!
Internationalization should be an afterthought, always! When starting to code your stuff, hardcoding any strings is the way to go because the Gettext functions in WordPress are known to break things. If at all, Gettext syntax could be added in a future version. A year after first version, your support guy may go through your 700+ strings and add those stupid functions and syntax…
Borrow as many strings as possible from WordPress core files. Those strings never change in hundred years, so you’re always on the safe side. Also, adding your own unique textdomain to these strings is known as “altering WordPress core” which is strongly forbidden, even in the case of borrowing.
Do not use any textdomain at all. WordPress can determine your strings anyways, so it may or may not add “default” by default. Textdomains are from the Middle Ages, so again, why bothering?
Please do not add any loading function for your textdomain! Otherwise it might load existing language files for a certain language by default and you don’t want that. Think performance, baby! If any user on this planet may ever need the loading of languages out of the box, his or her support guy may add a little code snippet to do just that. You want your own code rather lean and clean.
Different textdomains in *one* plugin or theme are super cool. To show off a bit you should come up with crazy string names for your textdomains! This will add some kind of adventure to your newest releases. Also, you should never look for typos in your textdomain names as these may increase the adventure only further. So users need to find out on their own which textdomain is currently used and loaded (or not). Putting a little quiz in your code goes a long way! Clearly, you are doing anything possible to put a smile on your user’s faces :)
Add a little spice to your admin and frontend strings, put HTML markup to it! Translators will exactly know why this markup is there around those strings and in which context it may be useful. Add as much markup as possible to all translation strings. HTML is a common and popular markup language everyone is grown up with. Markup in translation strings also speeds up the translation process and extremely minifies the possibility of hard to debug errors later on.
Do not use any placeholders when implementing internationalization! Placeholders make things very complicated. Your code may already be very complex, so do not add any further burdens to the translation side of things. Placeholders are an endless source of confusion to translators anyways.
Context is for babies! English is an universal language so any context in translation strings is just not necessary. Translators will know from the string itself what it means and where it is used. Especially short words with more than one meaning are very very rare in English, aren’t they?
Do not add a default .pot file to your release! This would only increase the package size and the download of the ZIP file may take longer. And: As modern translation tools are totally familiar with WordPress’ way of doing (translation) things, users (or their developer partners) may scan your releases’ strings themselves and create their own .pot files on the fly.
You do not need any predefined “/languages/” subfolder in your release. Just keep your awesome folder and file structure and do not add such weird things for foreign languages. Users can always put their translation files wherever they want.
Be very smart and clever. Use constants, variables or other crazy nodes as your textdomain. It will speed up your coding. PHP Gettext never had any problems in parsing those constants, variables or other stuff. The usage of an unique text string as your textdomain would only be a sign for other developers that you are not a code monkey, wouldn’t it?
Do not name your textdomain after your plugin’s or theme’s slug. The slug (folder name) and the textdomain name should not be identical, otherwise it won’t look smart. Of course, there will be NO problems with increased usage of WordPress’ “language packs” this way!
Your child theme should never have its own textdomain or language files. It always should leverage the textdomain and language files of its parent theme. This way, adding another 50 (child theme) strings to the already 500+ strings of your parent theme will save you from maintaining yet another translation project. And yes, saved time is more money, isn’t it? Plus, the load_child_theme_textdomain() function in WordPress core was only implemented for internal testing and has no relevance for using in themes and child themes.
Usage of sprintf() and printf() in combination with markup, placeholders and Gettext functions and syntax should be forbidden by law. Whoever came up with the function names sprintf or printf should go into jail. If you use these functions in your code regarding internationalization it will make your code look illogical and bad.
Do not add the parameters for “Text Domain” and “Domain Path” to your plugin or theme headers! Otherwise, it will make those (plugin or theme) descriptions and other stuff translateable and would make your marketing copy there look bad in other languages. So, strip it out.
Do not update your default .pot files with every new release! This is time consuming and will delay the release of updates. Again, users can scan your stuff for themselves and don’t need any newly added strings in your releases immediately with every new version.
Do not use WordPress’ escape functions in combination with internationalization. Translation functions are secure by default so don’t add another layer of security or complexity. Minimalism rules. Escaping strings is just not necessary anymore, as it was said in this recent tutorial, someone googled somewhere at sometime.
Please load translations always and everywhere! This way, you make sure anyone will see your stuff. In the age of Broadband DSL and WiFi ac standard performance doesn’t matter anymore. Any decision to load translations only on the admin side or only on the frontend side is a relic of the past.
Load translations as late as possible! Do your stuff. Only let load translations as the last thing in your code. As internationalization was implemented as an afterthought anyways, it could fire on lowest priority. So, if any users complain that the widget description of your super awesome bling-bling-widget does not translate in their language, it doesn’t matter. That only would make things more stressful for you to even pay attention to translations in the Widgets admin.
Congrats! You have read all 20 rules. Now, go and make use of them! Using those rules will make your plugins and themes more useful, have them bring you more users, downloads, sales and profit. What an opportunity!
Disclaimer: These rules above may or may not contain humor, irony and satire. Go, find out for yourself.