So it depends, one 2 things:
- hardcoded HTML tags containing spanish text
- i18n api text, e.g.
echo __( 'string', 'textdomain' );
You want the latter, but the theme author may not have used that API
Hardcoded HTML tags
This is when the text is hardcoded in the file, e.g.
<p>spanish text</p>
<?php echo "spanish text"; ?>
There are 2 options here, and one of them is awful for performance:
- Create a child theme and replace the templates that have hardcoded text with i18n api calls ( choose this option )
- Use an output buffer to prevent anything being sent, then search replace it at the end ( avoid!!!! this is the bad option! )
For maximum flexibility, and compatibility with translation plugins, use the i18n translation APIs.
Note that the output buffer approach will cripple the time to first byte metric and induce performance hits and SEO penalties. It also won't change the language of the page when using plugin language switchers, but I've included it for completeness.
i18n and the Official internationalisation/localisation API
The translation API lets you specify the default string, and a textdomain, then you can tell WP about this and where your theme stores translation files containing these strings but in other languages. This data is stored as mo/po/pot files, and it's how vanilla WordPress translates its APIs.
Note that this API cannot be used for dynamic content from the database or other external sources, it's for static strings only. That's what plugins are for.
There are a number of these APIs but the most basic one is __( 'static string', 'textdomain' );.
For specifics on how to translate a theme, I recommend the dedicated chapters in the theme and plugin handbooks:
These will teach you how to enable localisation of your theme/plugin, and how to then use that to create language files. Your plugins should automatically switch between these once the support is added.
