Lately I’m doing a fair amount of i18n in WordPress themes. Most newer themes include some i18n support (especially the sandbox-based ones); but themes based on older and legacy theme template tend to include i18n-unfriendly code.
I’m trying to collect some good practices and advise for those trying to add i18n support to their themes:
- Read the WordPress documentation on i18n. Print their best practices, put them in a visible place and recite them before any i18n effort.
- Use plenty of format strings. Ok, you already read the best practices, so you known I’m repeating them here. For better format strings use descriptions and comments (the _c() function)
- Use boilerplate copy everywhere. Don’t be too original with the text you include in your theme; “Submit It” better than “Say It Pal!” for a submit button. If your theme includes strings used by most other themes, chances are those strings are already i18n and l10n in . You can always have private copies of your theme with unique headers, titles, and button; the version you share should be as plain and simple as possible.
- Keep out strings that need no translation: and don’t skip small strings subject to translation; alt and title html parameters, submit buttons value, next|prev_post_link and other wp template tags, all accept i18n. See the next two samples; why “Comments” is left out of the _e() function?; is there a translation for ‘|’ in any language?
<?php _e($numComments, ‘XXXXXXX’); ?> Comment(s)
__(’ | ‘)
The last and best tip is to use a theme with good i18n support and clean code as base template; sandbox is a great, clean, and fully i18n WP theme.
