Custom Work

Problem:
You are developing a site and want to display both the English and Welsh translations of the company name on the same template using

bloginfo('name')

. However, using the Site name for English and the tagline for Welsh causes issues when the Site name is translated in String Translation.
Solution:
We recommend registering the strings manually with fixed source values to ensure they display correctly in both languages on the same page. Here’s how you can do it:

add_action( 'init', function() {
    do_action( 'wpml_register_single_string', 'site_settings', 'blogname_en', 'Your Site Name in English' );
    do_action( 'wpml_register_single_string', 'site_settings', 'blogname_cy', 'Your Site Name in Welsh' );
});

After registering the strings, you can retrieve them on the frontend with the following code:

$en = apply_filters( 'wpml_translate_single_string', 'Your Site Name in English', 'site_settings', 'blogname_en' );
$cy = apply_filters( 'wpml_translate_single_string', 'Your Site Name in Welsh', 'site_settings', 'blogname_cy' );
 
echo esc_html( $en ) . ' ' . esc_html( $cy );

This approach ensures that both the English and Welsh names appear on the page regardless of the selected language.

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 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 this does not resolve your issue, please open a new support ticket.

Problem:
The client is experiencing an issue where a custom post type 'projekt' displays duplicate entries in a secondary language (Swedish) despite setting the language parameter in WP_Query. The query fetches posts from both the default (Polish) and secondary language, leading to content duplication on the Swedish page.
Solution:
We recommended removing the 'lang' => $current_lang from the WP_Query and testing without it. If the issue persists, it might be related to other parts of the custom code. We advised testing the issue in a minimal environment using a default WordPress theme and only essential plugins to confirm if the problem is related to WPML or the custom code. Additionally, we provided a working code example for querying WooCommerce products to demonstrate a similar setup that functions correctly. If the problem continues, further debugging of the custom code or consultation with a developer might be necessary.

Please note that this solution might be outdated or not applicable to your specific 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 issue persists, please open a new support ticket at WPML support forum.

Problem:
You are working on a site under development and trying to translate pages using the WPML plugin. You encountered issues with custom Gutenberg blocks after translation, specifically an "Attempt Block Recovery" error.
Solution:
1. We created a minimal installation of WordPress, WPML, and all necessary WPML add-ons, and themes for you to replicate the issue.
2. Upon further investigation, it appears the issue arises from a mismatch between the stored attribute in the block comment and the actual rendered HTML. For example, the attribute might say

btntext: "View all testimonials es"

but the actual HTML renders as View all testimonials a. This discrepancy causes Gutenberg to flag the block as invalid.
3. To resolve this, manually adjust the mismatch in the code view. Ensure that the block defines the attribute from the anchor text correctly in your block.json or registerBlockType and in your save() function render. Consult with your developer to make these adjustments.

If this solution does not apply to your case, or if it 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 issues persist, please open a new support ticket.

Problem:
The client is experiencing an issue where the

$_POST

variable returns empty when the WPML plugin is active. This problem occurs because the 'action' parameter of the form includes a language parameter (?lang=en), causing a redirect that fails to forward the form data to the intended destination.
Solution:
We recommend removing the language parameter from the 'action' URL if the default language is English, as this will prevent unnecessary redirects. For handling multiple languages, consider setting up the 'Different languages in directories' option available in WPML -> Languages. This setup helps manage language-specific URLs more effectively. Before making changes, ensure to back up your website and database, and if possible, test these changes on a staging site first.

If this solution does not resolve your issue or seems outdated, please check the related known issues and confirm that you have installed the latest versions of themes and plugins. If the problem persists, we highly recommend opening a new support ticket for further assistance.

Problem:

The client needs to add sub-languages in the WPML language switcher and display the slug as desired, such as

https://w****apps.com/en/can/

when clicking on Canada.

Solution:

We explained that WPML does not support sub-languages like */en/europe/* or */en/can/* as they are considered pages within English, not new languages.

We offered two solutions:

Option 1: Keep them as Pages/Categories
Create them as pages or categories within the English site and translate them accordingly.

Option 2: Use Language Variants
For different English versions (Canada, UK, US), WPML allows the creation of custom languages, which are treated as separate languages and not nested under /en/. For example:

/en-ca/ → English (Canada)

/en-gb/ → English (UK)

/en-us/ → English (US)

To add a custom language in WPML, follow these steps after a full site backup:
- Go to WPML >> Languages >> Site Languages
- Click on the Edit Languages link
- Add a new language (example: English (Canada), code en-ca)

For more details, please refer to the following documentation:

• Editing WPML's Languages Table
• Google's Guide on Localized Versions

If this solution does not apply to your case, or if it 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 further assistance is needed, please open a new support ticket.

Problem:
The client was experiencing an issue where strings translated using the

__('...');

function were not translating correctly for some languages, despite working previously. The issue was observed on a live site, while a local development site with outdated plugins did not exhibit the problem.
Solution:
We first confirmed that the client was using the gettext method for adding code inside their theme and translating strings via WPML > String Translation. We then suggested regenerating custom MO files from the WPML > Support > Troubleshooting page. Upon further investigation, we discovered that the client's theme was missing the text domain definition in the style.css file. After adding the required text domain and rescanning the theme's strings, we removed and re-translated a specific string to ensure WPML generated a fresh translation file, resolving the issue.

If this solution does not apply to your case, or if it seems outdated, we recommend checking the related known issues, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. Should the problem persist, please open a new support ticket.