Skip Navigation

This thread is resolved. Here is a description of the problem and solution.

Problem:
The client is unable to find labels from a View created with the Advanced Custom Views Framework in the WPML String Translation. The labels were set up in a View linked to custom fields and a custom post type created using the Advanced Custom Fields (ACF) plugin. Although the labels are included in a language file generated in the child theme, they do not appear in String Translation.
Solution:
We recommend the following steps to make the labels from the Custom Views Framework translatable:
1) Modify one string in the View to ensure it includes a text domain.
2) Check the generated file in your child theme to see if it updates with the new string.
3) Rescan the child theme in WPML -> Themes & Plugin Localization.
4) Verify if the strings now appear in WPML -> String Translation.

Please note that this solution might be outdated or not applicable to your specific case. If these steps do not resolve your issue, 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 at WPML support forum.

This is the technical support forum for WPML - the multilingual WordPress plugin.

Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.

Tagged: 

This topic contains 4 replies, has 2 voices.

Last updated by Mary 2 weeks, 3 days ago.

Assisted by: Marcel.

Author Posts
November 6, 2024 at 4:24 pm #16373714

Mary

Background of the issue:
I'm trying to translate labels set up in a View created with the Advanced Custom Views Framework plugin. I have created a custom post type and custom fields using ACF. I then created a View using Advanced Custom Views and linked it to my group of custom fields. I set Advanced Custom Views to use Blade and I activated their file storage system so that a language file was created in my child theme. In the file, it says 'This file was generated automatically and contains instance labels for easy detection by multilingual tools.' and it does include all the labels from my View.

Symptoms:
I can't find the labels from my View in String Translation. Everything that was set in ACF is translatable, just not what was set up in the Custom Views Framework.

Questions:
Why can't I find the labels from my View in String Translation?
How can I make the labels from the Custom Views Framework translatable?

November 7, 2024 at 10:49 am #16376425

Marcel
Supporter

Languages: English (English ) German (Deutsch )

Timezone: Europe/Madrid (GMT+01:00)

Hi,

Please be aware that Advanced Views is not certified for WPML, so we cannot guarantee that it fully supports the proper use of getText() calls.

The generated multilingual.php file lacks the required textdomain in its getText() calls, as outlined here: https://wpml.org/documentation/support/translating-the-theme-you-created/#adding-gettext-calls-to-php-code.

For reference, the correct use of textdomain is shown in the example code here: hidden link.

Best regards,
Marcel

November 7, 2024 at 12:47 pm #16377480

Mary

Yes, in that support page (hidden link), it says "Advanced Views uses the built-in WordPress translation function __('field label', 'themeDomain') for all View and Card labels. This allows you to translate labels seamlessly using your preferred multilingual plugin, eliminating the need for creating a separate View or Card for every language."

So I'm not sure why I can't see the labels automatically in the string translation?

What I understood was that I had to activate their File system storage so it would create a scannable file in my child theme for WPML and other multilingual tools, but what you are saying is that I need to edit this file with the correct textdomain? If so, which textdomain do I have to use? My theme's (generatepress)? The ACF Views's textdomain (acf-views)?

Lastly, I did add a label manually in the template (<h2>{{ __('Coordonnées', 'generatepress') }}</h2>) and it was automatically added to their multilingual file in my child theme (last line in the attachment), but I still don't see it in string translations, even after rescanning the file for new strings.

I will contact them to see that I'm following their steps correctly, but if I am, is there a reason why I can't see the strings in WPML even when I add the textdomain (as I did for one string as seen in attachment)?

multilingual_withtextdomain_screenshot.jpg
November 7, 2024 at 3:00 pm #16378450

Marcel
Supporter

Languages: English (English ) German (Deutsch )

Timezone: Europe/Madrid (GMT+01:00)

Hi,

in theory, yes, but this plugin works a bit differently. Typically, a getText() call is made directly within the plugin's PHP file, not in a generated file. The text domain itself doesn’t matter much—it’s just an identifier. You can try using "test" as a placeholder.

Lastly, I did add a label manually in the template (<h2>{{ __('Coordonnées', 'generatepress') }}</h2>) and it was automatically added to their multilingual file in my child theme (last line in the attachment), but I still don't see it in string translations, even after rescanning the file for new strings.

This seems to be the main issue—the getText() call wasn’t set up correctly. If you adjust it here, it should generate properly in the file.

Here are the steps to try:

1) Modify one string, ensuring it includes a text domain.
2) Check the generated file in your child theme to see if it updates.
3) Rescan the child theme in WPML -> themes & plugin localization.
4) Verify if the strings appear in WPML -> String Translation.

Best regards,
Marcel

November 8, 2024 at 7:56 pm #16383422

Mary

Thanks. I did what you said and it worked for the label I had created manually, but not for the others.

That said, I did hear back from the author of the plugin. They explained their plugin picks up the text domain automatically, based on the ‘Text Domain’ setting, defined in the heading of style.css of the theme. Since my child theme didn't have a text domain setting, it wasn't working. Now that I've defined it, it works.

Thank you for your time.