[Resolved] Custom strings from child theme aren't translated
This thread is resolved. Here is a description of the problem and solution.
Problem: The client is experiencing issues with translating custom strings on their WordPress/WooCommerce site in German, which appeared after updating to Astra ver. 4.13.2 and the latest versions of WPML CMS and WPML String. The affected strings, mostly from functions.php in the child theme, are not appearing translated on the frontend despite being translated in WPML's String Translation.
Solution: We recommend the following steps to address the issue: 1. Temporarily disable all plugins except for WPML, WooCommerce Multilingual (WCML), and WooCommerce to rule out conflicts with third-party plugins. 2. Navigate to WPML → Support → Troubleshooting and run the option: “Show custom MO Files Pre-generation dialog box”. 3. Proceed to WPML → Theme and plugins localization. A popup should appear indicating that WPML needs to generate .mo files. Follow the instructions to generate these files. 4. Ensure that your custom strings are correctly wrapped in gettext calls such as __() and _e(), specifying your text domain. For more details on adding gettext calls, visit Adding GetText Calls to PHP Code. 5. Scan your child theme for new strings via WPML → Theme and plugins localization to register them for translation. 6. Confirm that the text domain 'structurababy' is properly loaded in your theme. For guidance, refer to load_theme_textdomain and Text Domain. Remember to back up your database before making any changes.
If these steps do not resolve the issue or if the solution becomes outdated, we highly recommend checking related known issues at https://wpml.org/known-issues/, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. If the problem persists, please open a new support ticket.
This is the technical support forum for WPML - the multilingual WordPress plugin.
Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.
We have an issue translating some custom strings on our WordPress/WooCommerce website. Our primary language from the start has been set as Bulgarian and our secondary language we have an issue with is German.
These are some the strings in question and how they are added/where they come from. The affected strings mostly come from functions.php in the child theme. I must mention that the translations stopped working on the frontend once we updated the website to Astra ver. 4.13.2 and WPML CMS and WPML String to the latest versions. Once the issue appeared, we restored a backup to a version that worked, including the database, but alas no change - it remained broken.
1. Checkout page (hidden link): Абониране за нюзлетър и получаване на още безплатни ресурси и специални промоции
- this comes from plugin: Mailchimp for WooCommerce by author Mailchimp
- it did not detect the string, we found it in admin texts and added it to String translation => translated it: hidden link
- on the frontend in our DE version, it remained in Bulgarian and we "hacked" it by using JS for the translation: hidden link
- appears in String translation and is translated: hidden link, but doesn't appear on the frontend
2. Checkout page (hidden link): Име/инициали на бебе
- this comes as a custom field added in functions.php in our child theme, used like this: hidden link
3. Checkout (hidden link): "Потвърждавам, че с финализирането на поръчката и изтеглянето на този дигитален продукт се отказвам от правото си на отказ съгласно законодателството за защита на потребителите в ЕС." + relevant error messages
- used in functions.php in our child theme
- appears in string translation and is translated: hidden link, but doesn't appear on the frontend
- we again "hacked" it by using using JS to translate: hidden link
4. Blog (hidden link): "Най-нови" and "Изчисти" (appears if you've selected a filter): hidden link
- used in functions.php in our child theme like this: hidden link
- the strings appear in String translation and are translated (еx. hidden link) but don't appear on the frontend
These are a few examples, but overall it seems that there is a more general and global issue, which only resulted after updates - it's as though String translation is not taken into consideration at all.
Some things we checked but didn't provide a solution on our end:
- duplicates ❌
- missing translations ❌
- wrong domain ❌
- language ❌
Please check and let us know what the issue is and how to fix it. We remain available if you have questions. If you enable the credentials field, we are ready to provide access.
As a first step, please check whether the issue persists after temporarily disabling all plugins except WPML, WooCommerce Multilingual (WCML), and WooCommerce. This will help rule out any third-party plugin conflicts.
If the issue still occurs, please try the following:
1. Go to WPML → Support → Troubleshooting
2. Run the option: “Show custom MO Files Pre-generation dialog box”
3. Then go to WPML → Theme and plugins localization
4. A popup should appear: “WPML needs to generate .mo files”
5. Proceed to generate the new .mo files
If the issue is not resolved, please check your custom strings to ensure they are correctly wrapped in gettext calls (e.g., __(), _e(), etc.). After that, go to WPML → Theme and plugins localization and scan your child theme for new strings. This will register them in WPML’s String Translation, where you can provide translations.
hidden link
Adding GetText Calls to PHP Code
In PHP, wrap all the hard-coded strings in gettext WordPress localization functions like __() and _e(). Specify a text domain to uniquely identify translations for your theme or plugin.
The __() function returns the strings
__('Hello, world!', 'your-text-domain');
The _e() function echoes a translatable string
_e('Hello, world!', 'your-text-domain');
These functions find the correct translation in the specified locale and domain. If no translation is available, the original string will remain unchanged.
We followed these steps but we didn't see any difference. The issue doesn't seem to be related to finding or translating the custom strings using String Translation (the strings exist with the correct text domain and are translated) but with outputting the correct language version of these strings on the frontend.
We also tested if there is an issue with the locale detection but that also isn't the case.
Let me know if you need anything else to troubleshoot further.
Can you please show me how you are loading the text domain 'structurababy' in your current theme?
We just released WPML update. Please update your WPML plugin and add-ons to the latest version, 4.9.4, to benefit from the latest bug fixes and improvements. This may not necessarily resolve your problem; however, we need to work on the newest code available to troubleshoot the issue best.
You can check the latest released versions under "My Account -> Downloads" on this site. Instructions to update can be found here: http://wpml.org/faq/install-wpml/
If you do not see the updates, you might need to click the Check for updates button in the Plugins → Add New Plugin → Commercial tab.
We are using the text domain 'structurababy' in our custom strings (e.g. __('My string', 'structurababy')), but we are not explicitly loading it with load_theme_textdomain() because these strings are intended to be picked up and managed via WPML String Translation rather than theme language files. Exact examples have been provided in my first message. Please advise how it should be changed, if necessary.
WPML Multilingual CMS has been updated to the latest version. Indeed it did not fix our issues. Please provide a relevant solution.
You can try loading your text domain via:
WPML → Theme and plugins localization → Localization options, and enable the option:
“Automatically load the theme’s .mo file using ‘load_textdomain’.”
If this does not resolve the issue, I strongly recommend loading the text domain following the official WordPress guidelines:
