Problem: Media URLs do not appear in ATE for translation when media is added directly from the Media Library using blocks, as the 'media ID' is used and the image is translated via Media Translation. Solution: If you're experiencing this issue, we recommend you follow these steps to use different media in translations: 1. Ensure you are in the default language (from top admin bar). 2. Navigate to the Media Library and add new media if needed, or skip this step for existing media. 3. Go to WPML -> Media Translation. 4. Locate the image or video you want to translate. 5. Click the pencil icon under the corresponding language flag to add/edit the translated version of the media. 6. Upload the translated version of the media by clicking "Use a different file" and select the corresponding media to upload. 7. Optionally, set the translated name in the input field under the image field. 8. Click "Save media translation" button. After these steps, the translated version you added should be displayed on the frontend for that translation.
Please note that this solution might be irrelevant if it’s outdated or not applicable to your case. We highly recommend checking related known issues, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. If the issue persists, please open a new support ticket.
Problem: You are using WPML with the Kadence theme on your website and experiencing issues with translations not appearing on the live page, despite being translated in the backend. Specific problems include untranslated elements in the header, footer, and other areas.
Solution:
1) For the untranslated button in the header, we found the string "[kadence_conditional_header_3996]header_button_label" in Admin Strings. It was not included in String Translation, so we included it, corrected the language of the string, and translated it. It should now display correctly.
2) For the footer widgets using blocks, refer to this guide on translating widgets. We demonstrated this process in a video, showing how to display the same widget in multiple languages and how to duplicate and set language/translate the rest of the widgets.
3) The form requires further investigation and possibly a custom XML config. We recommend opening a separate ticket for this issue.
4) The 'Case Studies' posts have not been translated yet. Please translate these posts for them to appear correctly.
5) For SEO work on the Swedish page, ensure that media (images and videos) are translated or different for each language to display correctly. If issues persist, consider opening a separate ticket with detailed steps or a video recording of the problem.
If this solution does not resolve your issue or seems outdated, 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 necessary, please open a new support ticket at WPML support forum for further assistance.
Problem: The client has moved a development site from a subdomain to another domain, which is the live domain, and is unsure what to select in the WPML message received in the backend regarding sharing translation memory and automatic translation credits. Solution: 1. If the client plans to continue using the development website, they should select 'Yes' to share automatic translation credits and memory between the two websites. 2. If the development website will no longer be used, WPML will transfer all related translation memory and account details to the new live website. 3. To complete the process, the client should: - Go to WPML → Translation Management. - Click the Tools tab. - Expand the Connected Sites section. - Copy the migration code. - Paste it on the live website to connect them. For detailed instructions, please refer to the following documentation:
Problem: If you're experiencing very slow backend performance with WPML when updating products, taking up to 20 seconds, we have investigated this issue.
Solution: First, check your database's
_options
table for any unusually large entries that could be affecting performance. You can use the following SQL query to identify large autoloaded options:
SELECT option_id, option_name, sum(char_length(`option_value`))/1024 as size FROM `wp2x_options` WHERE `autoload` = 'yes' GROUP BY option_id ORDER BY size DESC
If you have tested and the issue persists, or if this solution doesn't seem relevant to your situation, please open a new support ticket with us for further assistance: Contact WPML Support
