All hard-coded labels and outputs should be wrapped in internationalization tags and refer to the site’s custom text-domain
Introduction
Even if a site is not slated to be translated, all hard-coded strings, labels, and outputs (including patterns, blocks, templates, etc.) in PHP and JavaScript should be wrapped in internationalization tags to future-proof the site. A custom text domain should also be established.
Decision
To prepare the theme to leverage internationalization functions, first have a proper text-domain in the theme header:
/*
* Theme Name: A Kala Theme
* Author: Kalamuna
* Text Domain: kalapress-project
* Domain Path: /languages
*/
Then use that text domain with the appropriate internationalization function throughout the theme. For example:
<?php echo _e('The default label for the front end.', 'kalapress-project' ); ?>
If HTML is needed then it should be escaped using the appropriate function for the use case:
<h1><?php esc_html_e( 'Title', 'kalapress-project' )?</h1>
Context
Clients sometimes decide later in the life cycle of the site to add translations for one or more additional languages. Having to go back through old code is more costly and time-consuming than simply providing for it while the code is being written. Additionally, sometimes text labels exist in a template part like the footer that needs to be made available for translation.
Consequences
- Learning curve: Developers might not know which internationalization functions to use, as well as other functions like
sprintf()and/* translators …*/comments depending on the functionality requested.
Exceptions
- This ADR only applies to output generated by code written by Kalamuna, not anything provided via plugins like Gravity Forms where the entire output is controlled by the plugin.
Additional Resources
None