Problem: If you're unable to access the Advanced Translation Editor (ATE) on your site, and clicking the icon to edit/create translations redirects you to the transaction dashboard, with an error message 'the translator could not be assigned to the job' appearing briefly, the issue might be related to database privileges and missing database columns. Solution: First, check your debug log file for any explicit denial of CREATE privileges in your database. This issue is indicated by an error from MySQL, not WordPress or WPML. If you find a line similar to
Commande CREATE refusée à l'utilisateur " username "@" host "
, it means the database user does not have the necessary CREATE privilege. To resolve this, execute the following SQL query to restore the correct privileges:
GRANT CREATE, ALTER, INDEX, DROP ON `your-database-name`.* TO 'your-database-user'@'%';
Next, ensure that all required columns are present in your database tables. Due to the privilege issue, some columns necessary for the latest WPML version might not have been created. Run the following SQL query to add the missing columns, making sure to replace 'wp_' with your site's table prefix if it differs:
ALTER TABLE `wp_icl_translate_job` ADD `wpml_words_to_translate_count` int unsigned NULL, ADD `wpml_automatic_translation_costs` int unsigned NULL AFTER `wpml_words_to_translate_count`;
If these steps do not resolve your issue or if the solution seems outdated or irrelevant to your case, 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 problems persist, please open a new support ticket.
Problem: The client is testing the migration from Divi 4 to Divi 5 locally and encountered a WPML message unsure how to respond, thinking local testing wouldn't affect anything. Solution: We understand the situation and it's great to test major updates like Divi 4 to Divi 5 on a local or staging site. The WPML message seen in the local environment is likely related to translation services communications, which can create inconsistencies with the actual production site. To prevent the test site from interfering with the translation services of the production site, we can instruct WPML that this environment is solely for testing purposes. This will block critical requests to translation services. Here are the steps to follow: 1. **Access the
wp-config.php
file of your local site.** You can find it at the root of your WordPress installation, accessible via your local file manager or a code editor. 2. **Add the following line of code** just before the line `/* That's all, stop editing! Happy blogging. */` (or equivalent):
file. After adding this line, the local site should no longer attempt to interfere with the translation services, and the WPML message should disappear. Could you try this and let us know if the message persists?
If this solution does not resolve your issue or seems irrelevant due to being outdated or not applicable to your case, 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.
Problem: You are encountering two issues with bulk machine translation in WPML. The first issue is that parts of the content are not translated despite the translation manager indicating complete translation. The second issue is that some pages appear empty after translation. Solution: This is usually related to the emojis that are being used on the content. The DB tables are using utf8mb3, which is insufficient to translate contents with emojis. To resolve these issues, we recommend running specific SQL queries on your production database to change the collation from utf8mb3 to utf8mb4 for certain tables. First, ensure you perform a full database backup. Then, execute the following SQL queries:
ALTER TABLE `wp_icl_strings`
ROW_FORMAT=DYNAMIC,
CONVERT TO CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;
ALTER TABLE `icl_string_translations`
ROW_FORMAT=DYNAMIC,
CONVERT TO CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;
After running these queries, update the page in the primary language and retranslate it. If the issue persists or if this solution becomes outdated, please check related known issues, verify the version of the permanent fix, and confirm that you have installed the latest versions of themes and plugins. If necessary, do not hesitate to open a new support ticket.