Dies ist das technische Support-Forum für WPML – das mehrsprachige WordPress-Plugin.
Mitlesen können alle, doch nur WPML-Kunden können hier Fragen veröffentlichen. Das WPML-Team antwortet im Forum an 6 Tagen pro Woche, 22 Stunden am Tag.
Hintergrund des Themas:
I created a staging site versteckter Link with 8 languages (German is the main one). I updated all translations from German to other languages, and everything was fine. Today, I updated some pages in German and tried to start the automatic translation again.
Die Symptome:
WPML says that for many pages it is not possible to start the automatic translation because the original language for many pages is now Czech. This issue has happened multiple times, causing chaos in the translations.
Fragen:
Why does WPML change the original language of many pages to Czech or other languages after updating some pages in German?
How can I prevent WPML from changing the original language of pages automatically?
All pages have been 100% created from german and then being translated. The same issue occurs with blog articles and layouts....
I am trying to work this out with our 2nd tier, but we may need a bit more information on reproducing this, there needs to be some step that causes database corruption. Because it is very difficult to know what caused it after the damage has been done.
The thing is that the customer is also working on the staging website and if the database broke, I don’t think it’s a good idea (We are doing backups of it but nonetheless..)
On Saturday, I created a third copy of the website under stefanomontuschi.com
Nobody has access to this website apart from me.
Do you prefer to have access on it so that you can work on the database without problems?
The homepage seems fine but for example the page "contact" and "sectors" are now in czech.
On the frontend is everything fine but in the backend we cannot start the update of the translation from german to czech, because now all of a sudden it recognize these pages as czech.
1. **Verify Database Entries**: Ensure that the database entries for the page with ID 3850 are correct, check this before the migration and create a screenshot. Specifically, check that the source language code for 'de' (German) is not blank and the source language code for 'cs' (Czech) is not null. Only one language should have a null or blank source language code.
2. **Review Migration Process**: If the site was migrated, verify that the migration process correctly handled null values. It appears that nulls may have been converted to empty values during export. Correct any inconsistencies that may have arisen during this process.
3. **Correct Language Codes**: Adjust the database so that the source language code for German ('de') is properly set, and the source language code for Czech ('cs') is either correctly populated or marked as the original if it is the default. There should only be one element with a null or blank source language code.
4. **Check for Corruption**: Investigate any signs of database corruption, as indicated by the mismatched and empty source language codes.
The site has not been migrated. The live website has always been hunterlab.de and we created a staging under staging2.webtofly.de
The page with the ID 3850 is the contact page. The source language for this and all pages has to be german because german is the main language of the site.
We created every single page in german and then translated it.
What do I have to do exactly. I am not so familiar with database entries and so on...
At this point we don't have any solutions to offer as we don't know the cause. There may be some corruption during the site migration not even caused by WPML but by the migration software/process.
Try this:
1. Verify the database entries on the original site where everything functions correctly. Capture a screenshot showing the same data as in my provided screenshot, but from the functioning site.
2. Perform the migration again.
3. Check the same database entry post-migration.
4. Confirm that the test site is working properly.
5. If the issue reoccurs, please check the same database entry and send us the screenshot.
I checked the live website and everything seems fine. The database entry is the same as in the staging site. (the only difference is that on the staging site we actually have the problem)
Are you sure that I have to perform the migration from staging to live? Because in this case even if the database entry is the same, we will push the problem to the live website....
I attached all the screenshots from the live website
Ok, on the website where this happens, you can try this plugin: https://wordpress.org/plugins/wp-security-audit-log/ as it can record some WordPress database changes. And if this happens again let us know, we can check to see if there are some clues.
Other than that I have no ideas as I don't know what triggers this. Perhaps some other entries throughout database are also altered, not just WPML tables, so this may not be on WPML part at all.
1) I delete the staging site and created a new one from the live site.
2) I install the plugin on the new staging copy so we can start from 0 again
3) we observe if the same issue happens again
