Home›Support›English Support›[Resolved] Split: The japanese version of our homepage contains translations in ATE but shows up blank on the front-end
[Resolved] Split: The japanese version of our homepage contains translations in ATE but shows up blank on the front-end
This thread is resolved. Here is a description of the problem and solution.
Problem: The client is unable to translate strings from a PHP file on their website because the strings are not wrapped in the necessary WordPress functions (__() or _e()). Solution: We recommend wrapping the hard-coded strings in the PHP file with GetText functions to make them translatable. You can find detailed instructions on how to find strings that don't appear on the String Translation page and how to wrap texts in GetText calls here:
The _e() function retrieves and displays a translated string immediately, useful for simple outputs:
_e('Hello, world!', 'text-domain');
If these functions are missing, it indicates that the theme may not have been developed with translation in mind. For automated assistance in adding these functions, you might consider using tools like PHP Code Beautifier and Fixer (PHPCBF) alongside PHP CodeSniffer (PHPCS), though manual adjustments might still be necessary for complex cases.
If this solution does not apply to your case, or if it seems outdated, please check the related known issues, verify the version of the permanent fix, and confirm that you have installed the latest versions of themes and plugins. We highly recommend opening a new support ticket if you need further assistance: WPML Support Forum.
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.
Thanks Mihai. Appreciate all that information. I have translated the home page and the option to switch to Japanese appears in the footer now, however when switching to Japanese the page's content is blank. Any thoughts on why this might be?
Before one of my colleagues takes this ticket I would like to ask you to follow these steps:
- Edit the homepage in the original language
- Make a small change to the content
- Save the changes and update the translation
- Double-check if the issue disappeared
If you are using templates to display the content of the homepage, then double-check if the template is translated and published.
Please provide the results of the steps described above so my colleague can continue working on this ticket.
It worked, sort of. Some content is appearing, some of it translated, some not. Most of this content is created with Custom Fields, so I'll take a closer look at that documentation.
A couple of things point to the WPML installation not working as it should have, could I get your input on that? I'm not sure whether I should work granularly through piece of content to fix it (there's a lot), or just reinstall WPML and try starting over again.
For example, I selected 'automatic translation' during the install process, which didn't work. Support staff Mihai Apetrei was able to determine this was because WPML set itself up with the Classic Translation Editor rather than the Advanced Translation Editor. I assume the ATE is usually set by default, so I'm wondering why this happened.
If WPML was installed with CTE, is it possible there are other settings that have been set incorrectly?
If all of the above is done and if the home page translation is still blank, would you be willing to provide me with WordPress and FTP credentials so I could investigate the issue directly?
We've had some success getting translations to appear following Bruno's comments above.
We're still having issues with theme file strings not being translated. There is an option in WPML for translating theme file strings but we're having trouble with it.
I'm posting here now to keep this ticket open. We should have more information and a request for assistance in the next 24 hours.
Languages: English (English )German (Deutsch )French (Français )
Timezone: Europe/Zagreb (GMT+02:00)
We're still having issues with theme file strings not being translated. There is an option in WPML for translating theme file strings but we're having trouble with it.
Would you be willing to provide me with WordPress and FTP credentials so I could investigate the issue directly?
And send me URLS/screenshot to show me which strings are causing the trouble?
Languages: English (English )German (Deutsch )French (Français )
Timezone: Europe/Zagreb (GMT+02:00)
The ticket was created within the 30-day refund period so the refund would be available even after this, but I hope I can help so that this is avoided.
Let me focus on this first:
1. A large amount of strings requiring translation aren't appearing in WPML's String Translation. I believe they require manual wrapping with the GetText call and I've contracted a developer to help with that.
Can you send me an example of such string? Where does it appear in the frontend and where in the theme files?
"as they have mentioned in their response, if the string does not have __() or _e() function used with it it wont be picked by any translation plugin.
This means the code is not written in a translatable way. I think considering that the only solution is to fix these string manually by wrapping them in __() or _e() depending on the usage."
It looks like there's a substantial amount of work to add the functions throughout the site. Would these functions normally already exist in a WP site's code, Bruno?
Languages: English (English )German (Deutsch )French (Français )
Timezone: Europe/Zagreb (GMT+02:00)
Yes,the __() and _e() functions are standard parts of WordPress and are essential for making strings translatable in WordPress themes and plugins.
__(): This function retrieves a translated string but does not display it directly. It is used when you need to assign the string to a variable or use it in a more complex way, such as concatenating it with other strings.
If these functions are missing, it likely means the theme was not developed with translation in mind. The developers might not have prioritized internationalization (i18n) or weren't familiar with the WordPress standards for making content translatable.
You can automate parts of the fixing process using tools like PHP Code Beautifier and Fixer (PHPCBF), which works alongside PHP CodeSniffer (PHPCS). But this is for our https://wpml.org/contractors/ and this process may not handle every case, especially complex or concatenated strings.
It's normal for static strings to be translatable, but ideally, most translatable content comes from dynamic sources like posts and pages so it is a bit unclear to me why so many parts of the theme were coded this way.
Ok thanks Bruno. Understood and we'll continue working on those string compatibility fixes.
2. A large amount of content translation for this website needs to be managed in String Translations, however the taxonomy of the strings seems random and it's difficult to know which string is being used where.
In dashboard WPML > String Translation, the domain dropdown filter isolates strings associated with my theme ('ghoul'), however the organisation of strings from there seems random (screen attached).
Is there any way strings can be organised better, for example by the pages they appear on?
