Background of the issue:
I'm having a handful of issues with a site, several of which are affecting the stability of the translations. The site is hidden link. We thought we had a workflow in place for deploying translations as a part of code updates on the site. We noticed that when we made updates via String Translation, this updated the relevant textdomain-named .MO files in the languages folder, so we would commit those changes and then push them up. This seemed to update the translations on the production version of the site.
Symptoms:
1. The site is reporting on the Plugins page that "You are using an unregistered version of WPML and are not receiving compatibility and security updates.". However, when I click on the link to "Register Now" (navigates to hidden link) I get a message that says "Sorry, you are not allowed to access this page.". I am using the main Administrator account with full permissions on the site.
2. I've had issues recently with translated text defaulting back to their original English versions. I checked in the String Translations and they were still present. When I enabled "Auto register strings for translation" at the bottom of the String Translations page and then re-checked the page, the correct translation was now in place.
3. Some part of our commit-and-deploy .MO translations workflow is unstable. Translations that were once on production (and not independently added there) would become untranslated upon deploy. We eventually noticed also that sometimes when we added translations the .MO files would shrink, although we had no real way of understanding what was lost because they're binary files. This would usually correspond to the translations going "missing" on the production site.
Eventually I have tried to go the route of exporting the translations we had to .PO files, manually making changes there, then reimporting those .PO files upon deploy (while continuing to commit updates to the .MO files in parallel just in case). Even this doesn't always seem to work--in a recent case where translations seemed to go missing on production importing the .PO files didn't update or restore missing string translations I expected it to--I had to input the change manually in String Translations.
Questions:
Why am I getting a 'Sorry, you are not allowed to access this page.' message when trying to register WPML?
Why do translations default back to their original English versions and how can I prevent it?
Why does "Auto register strings for translation" sometimes restore present but not visible translations?
Why would our .MO files ever shrink and lose translations?
Is there a recommended Git-based workflow for maintaining translations?
What should we change in our current workflow to make it more stable?
As documented in my initial post, I'm not able to access the registration page on production. I am able, however, to access the registration page on my local environment. I set up a Site Key for that domain and clicked the link to add the key to the site from the https://wpml.org/account/sites/ page (I had to modify the link slightly; see below). It pre-filled the Site key box, but when I saved it gave the error "Unable to register: Site key not matching". So I think I'm doing everything "right" but not quite getting there.
I'm wondering if maybe it has something to do with the site being based on Roots Bedrock and being installed with Composer? Composer by itself would not cause issues I think, but Bedrock does make the base admin directory of the site "/wp/wp-admin" instead of just "/wp-admin". Could be nothing, could be everything, just brainstorming here.
Thank you for the updates. I am consulting with our team for an expert opinion. We will get back to you soon. Please wait.
Please note that I have opened a new ticket for the an invalid site key defined issue. As per our support policies, we can only handle one issue per ticket. It will help us to serve you better and we can avoid discussing multiple problems in one ticket. I will get back to you soon on the latest ticket. Thank you for your understanding.
We have a couple of suggestions as a workaround for you. Please try it after a full site backup {mandatory} and let us know your feedback.
1) After the site migration, please visit WPML>>Support>>Troubleshooting and regenerate the Mo files by clicking Show custom MO Files Pre-generation dialog box >> Generate .Mo files
2) Adding the following constants in the wp-config.php file of the dev/staging and live/production sites also would help.
Thank you Bigul! I will work to review and implement those constants.
Is there a way to trigger the "Generate .MO Files" from command line? If that's something that needs to be done regular on a per-deploy basis then being able to issue a WP CLI command as a part of our deploy script would be ideal.
Something we discussed on 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.
New threads created by Bigul and linked to this one are listed below:
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.
---
I looked into those constants. The documentation on WPML_ST_SYNC_TRANSLATION_FILES reads "By default, String Translation only stores MO files on one server. This means that if your site runs on multiple servers, all the requests handled by other servers do not translate the strings." This seems to indicate it might be used more for multisite installations, rather than a site where the whole codebase including the MO files is replicated between environments. Is there any more documentation that expands on this?
The WPML_ST_SYNCED_FILE_MANAGER constant does not seem to have any documentation anywhere. Is there and documentation as to what that does, if it does anything?
Thank you for the feedback. It will not be possible to trigger the "Show custom MO Files Pre-generation dialog box >> Generate .Mo files" action from the command line.
However, the constants we shared with you yesterday should have a similar effect in regenerating the MO files, at least if the site hasn't been heavily customized. These constants can also be used in non-multisite environments. Unfortunately, we don't have any official documentation for the constant *WPML_ST_SYNCED_FILE_MANAGER*.
I'm going to go ahead and introduce these constants into my deploy pipeline for the site. That said, I still have very little information about what they're meant to accomplish. When I said I can't find documentation on WPML_ST_SYNCED_FILE_MANAGER, I had expected some explanation of the constant and it's use, not simply a confirmation that there was no public documentation.
What's the intended effect of these constants so that I may check it? So far all I have is that they "would help".
Notably another headline has been broken, visible while logged into the site (logging in circumvents the server caching) on the homepage. The string to be translated was removed from the String Translation list until "Auto register strings for translation" was enabled and the home page accessed. Unlike the translation issue that's been split into another ticket, this string translation was re-added and stayed up after "Auto register" was turned off, so I would consider this kind of issue the target of this task now that other tasks have split off.
These constants are now present on the production/live and staging versions of the site. I've not seen any changes to other issues presented on other tickets, and since the remaining issue here seems to come-and-go I've not been able to see if this corrects anything.
There's not presently a translation issue to record on this outside of the one already being captured in a screen request and split into that new ticket https://wpml.org/forums/topic/translation-of-the-strings-are-not-showing-in-the-frontend/ . I've resolved to do a screen capture the next time I come across one, though I am not sure how soon that will happen.
This ticket should be left open for the time being as it concerns the rest of the translation on the site being unstable, and I'll need to updated it as issues present themselves.
Did we get any more information about those constants?
I've come across an issue on a sister site, hidden link. I copied the database locally, and the site appeared translated. I went into the backend to look at string translations and found that no strings in the "ogletree" domain were appearing on the string translation page. When i moved to translate a string in the "ogletree" domain, all the other strings in the domain disappeared from the front end of the site.
I have captured this behavior in another Loom recording hidden link
It seems like the entries on the front end are driven by the existing ogletree-de_DE.mo file, but those translations are not brought into the string translation system. Why does this happen? How can I make it happen when pulling the MO file locally?
We're trying to manually manipulate some of the MO files generated by WPML, and using the msgunfmt cli tool we run into a lot of "read-mo.c:258: invalid multibyte sequence" which seems to strip out non-ASCII characters. Obviously losing all those umlauts and accents is a big problem. We think the issue is that there's no headers that describe the contents as UTF-8. Any idea why those headers wouldn't be present? Is there another way to decompile those MO files into PO files that doesn't break the translations?
The topic ‘[Closed] Several Issues: Registration Page Access, Disappearing Translations, Translations Only Appearing Whi…’ is closed to new replies.
