[Resolved] Translation of the strings are not showing in the frontend
This thread is resolved. Here is a description of the problem and solution.
Problem: The client reported an issue where translations were visible in the WPML String Translation system but did not appear on the site unless 'Auto register strings for translation' was enabled. When this option was disabled, the translations reverted to English. Solution: We provided a step-by-step solution to address the issue: 1) Navigate to WPML>>String Translation. 2) Search for and delete the problematic string from the 'pinegrow' text domain. 3) Go to WPML>>Themes and Plugins localization. 4) Scan the theme strings for translation. 5) Translate the newly added string again in WPML>>String Translation. Additionally, we suggested that the issue might be related to .mo files not matching the .po files used on the live site. We recommended: - Regenerate the .mo files from WPML>>Support>>Troubleshooting by using the 'Show Custom MO Files Pre-generation' dialog box and clicking 'Generate .Mo files'. - Clear all types of caches and check if the issue persists.
If this solution does not resolve your issue, or if it seems outdated or irrelevant to your case, please visit our support forum to open a new ticket. We also 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.
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.
Our next available supporter will start replying to tickets in about 0.96 hours from now. Thank you for your understanding.
Something we discussed in our original chat was working to find a demonstration of the errors we were seeing. I was able to see and record one specific issue on my local site that occurred while I was working on translations and take a video recording of it. That's available here
hidden link
This demonstrates the issue where the translation is present in the String Translation system, but doesn't become visible until we enable "Auto register strings for translation". Hopefully this helps provide some insight.
I'm realizing that issue is not resolved by Auto register either. As soon as Auto register is turned off it reverts back to the original english translation. That means the issue continues to be present on the production/live site hidden link
That translation-appearing-during-auto-register-only issue is therefore the highest priority, because I don't have a resolution at all. Please advise.
Welcome to the WPML support forum. I will do my best to help you to resolve the issue.
One doubt about the following. The local copy of the site is a fresh installation or a clone copy of your live/production site? Please confirm.
I was able to see and record one specific issue on my local site that occurred while I was working on translations
Please try the following troubleshooting steps (on local copy) after a full site backup{mandatory} and make sure the issue exists or not.
1) Go to WPML>>Support page, click on the Troubleshooting link (blue link in the middle of the page)
2) On the Troubleshooting page, please click on the following options in the *Clean up* section. Wait for confirmation of processing after each one.
- Clear the cache in WPML
- Remove ghost entries from the translation tables
- Fix element_type collation
- Set language information
- Fix WPML tables collation
- Assign translation status to duplicated content
- Fix terms count
- Fix post type assignment
- Cleanup and optimize string tables
- Show custom MO Files Pre-generation dialog box>>Generate .Mo files
This ticket was split off another ticket where I had already performed these steps after they were issued to me during a chat. I've gone ahead and performed them again for the sake of this ticket. Note that for this ticket I'm working with my production site, hidden link
Every step in this process alerted "Done" after clicking except:
- "Fix WPML tables collation" (displayed nothing, throbber just stopped),
- "Fix post type assignment for translations" (displayed a modal that said "No errors were found in the assignment of post types.")
- "Cleanup and optimize string tables" (Alerted that "Cleanup and optimization completed!")
- "Show custom MO Files Pre-generation dialog box" (Modal appeared, I clicked the "Generate .mo files" button, and it regenerated 17 items successfully)
The initial translation issue on hidden link continues to be present after those steps.
Yes, this specific auto register issue is also occurring on staging/local versions of the site. We can try hidden link where the issue is occurring here hidden link
We are still working on this issue and looking for the possible workarounds. But now unable to access the site frontend. It shows the following warning. Have you made any changes in the settings?
This page isn't working
****.site redirected you too many times.
Try deleting your cookies.
ERR_TOO_MANY_REDIRECTS
Sorry for the late response because of the weekend and holidays.
We have intentionally avoided interacting with the hidden link site in order to give you at WPML the best chance at finding and diagnosing the issue. As noted on the other ticket, we used some backend tools to confirm it was WPML causing the redirect issues. There does not seem to be any code changes, so we suspect some database configuration changes are causing the problem.
Please let us know if you would like us to pull a copy of the database back into the site and rebuild the test credentials.
Thank you for the details. The ticket is escalated to our second-tier team for further checking. We will get back to you as soon as possible. Please wait.
After reviewing the theme code our second-tier team has noticed that it has a lot of hardcoded translations. The parent theme loads the textdomain pinegrow but it looks like the child theme isn’t loading any textdomain, which may be causing the issue. Also, it is not loading it via load_theme_textdomain function as recommended here: https://developer.wordpress.org/reference/functions/load_theme_textdomain/.
For example, the string *Attorneys for this Practice Group* is from the textdomain pinegrow (parent theme textdoamin) and not from strong>ogletree (the child theme textdoamin)
Therefore could you please let us know if you're getting the expected results when using just the parent theme.
I'm assuming this is in reference to the od_translations function found in themes/ogletreefr/transaltions/translations.php . You're correct in assessing that it is not for a specific textdomain and that the theme is not correctly using load_theme_textdomain. However the translation for "Attorneys for this Practice Group" is not present in that list of translated items. Only WPML string translation is affecting that. It should not be relevant to this investigation.
> Therefore could you please let us know if you're getting the expected results when using just the parent theme.
When I switch to using the parent pinegrow theme I get the error where there are too many redirects. Disabling the OD Language Switcher plugin fixes the redirect issue (it apparently is dependent on that child theme). However, I'm still experiencing the same translation issue that initiated this ticket: Navigating to hidden link shows the English "Attorneys for this Practice Group" unless I have "Look for strings while pages are rendered" active on the back end. I am therefore not seeing the expected results.
I have left the site in the state of using the parent theme to help the tier 2 support not be distracted by other translation functionality.
Thank you for the feedback. I have shared it with our team. Just to make sure, on this site now you are only facing the translation issue with the *Attorneys for this Practice Group* string, am I correct?
The original ticket is closed because we thought it would be related to the issue we are discussing here. Hope you would like to collect more details about the following constants. Please confirm.
Honestly, the production version of the site is no longer experiencing translation errors because we have completely given up on the String Translation portion of WPML. The stability issues we experienced trying to manage the opaque MO files between environments and unclear/undocumented process led to too many times where the production site had translations fail. Those issues were detailed in the original closed ticket.
With those issues and the fact the we've seen no progress from support in nearly a month, the client was threatening to move away from WPML and our services completely without a fix. The issue was threatening our business. The "od_translations" function you saw in your last update was our workaround. It's fully implemented and consistent on all other environments of the site.
We've intentionally left the staging site you have access to un-updated so that the specific issue with this specific line can be debugged and fixed. I did not have any intention to address any other issue in this ticket--that's what the original ticket was for.
The fact that there are undocumented constants, which also seem to be undocumented internally for WPML, and yet are recommended in support scenarios is very difficult to understand to me. Yes, we'd love any documentation about those constants, but it was not the priority of this ticket. Those constants were not even the priority of the original ticket.
We've been working on this for a month (on my team, several months). We've seen no reportable progress from support. We have been left again and again with questions that are unanswered. The documentation is incomplete. Support is closing viable tickets that were awaiting responses from the WPML team. My confidence in WPML as a product is shattered. Is there anything, any progress on our outstanding issues that can be made or any plans moving forward?
Sorry for the inconvenience. The issues are happening due to compatibility conflicts with your customized theme and setup. You're using a custom child theme, a custom parent theme, and custom server workflows, which can cause various issues.
Our team is still working on this issue. We will get back to you as soon as possible. Please wait.
