Is it good to add a text domain as an argument to every __(), _e() and __n() gettext call such like these, even though I’m not planing to create my own translations?
__( 'Post', 'my-theme' );
_e( 'Post', 'my-theme' );
_n( 'One post', '%s posts', $count, 'my-theme' );
- The pro that I see when you add your Text domain is, it’s already
added if ever it came from your mind to create your own translations
and you will not be burden to add them when it comes.
- And the con is, you have added your Text domain to every
localization functions, but you don’t have your own translations or
localization files.
Reviewers can be found on Internationalization and Localization of WordPress Theme Developer Handbook.
Any thoughts about this?
Before we go into details, it should be noted that the guides you are referring to is only what it is, a guide. Just like coding standards (which not even the core developers stick to 🙂), the WordPress Handbook is just a guide to developers, it is not the alpha and omega.
The basic idea is to use this guide and implement these guideline in such a manner that one at least stay in some set boundaries while still maintaining the concept of these guidelines.
One guideline I accept as a non breakable or non bendable rule is that all strings should and must be in English, whether or not you writing a theme (or plugin) for a friend, yourself or for commercial use. Based on this, I also make my strings in a theme translatable as I’m using my themes on Afrikaans sites, and again, it does not matter whether or not I write it for my own use
But as I said, the handbook is just a guideline, and how you want to implement these guidelines in your enviroment is up to you and your specific usecase. Having your strings ready for translation does have the advantage of that if you want to commercialize your theme, everything is already there, and it will most probably help a lot if you thinking about a multilingual site. The pro’s here will always outweight any con’s there might be
