|
Hi,
I have now created a WPML XML Configuration for the widgets of "Directorist AddonsKit for Elementor". Note that usually our support will not create such configurations, but as my current workload allows me to assist, I am making an exception.
There are various problems:
Most of these widgets do not include any text that could be translatable with the WPML Translation Editor. Most of the data in those widgets is dynamic data that is built directly from the database.
The current WPML XML Config for all widgets of the plugin looks like this:
<wpml-config>
<elementor-widgets>
<widget name="directorist_all_listing">
<fields>
<field>header_title</field>
</fields>
</widget>
<widget name="directorist_search_listing">
<fields>
<field>title</field>
<field>subtitle</field>
<field>search_btn_text</field>
<field>more_filter_btn_text</field>
<field>more_filter_reset_btn_text</field>
<field>more_filter_search_btn_text</field>
</fields>
</widget>
<widget name="directorist_search_result">
<fields>
<field>header_title</field>
</fields>
</widget>
<widget name="directorist_category">
<fields>
<field>header_title</field>
</fields>
</widget>
<widget name="directorist_location">
<fields>
<field>header_title</field>
</fields>
</widget>
<widget name="directorist_tag">
<fields>
<field>header_title</field>
</fields>
</widget>
<widget name="directorist_user_login">
<fields>
<field>signin_username_label</field>
<field>signin_button_label</field>
<field>recovery_password_label</field>
<field>recovery_password_description</field>
<field>recovery_password_email_label</field>
<field>recovery_password_email_placeholder</field>
<field>recovery_password_button_label</field>
<field>signup_label</field>
<field>signup_linking_text</field>
<field>author_role_label</field>
<field>user_role_label</field>
<field>username_label</field>
<field>password_label</field>
<field>email_label</field>
<field>website_label</field>
<field>firstname_label</field>
<field>lastname_label</field>
<field>bio_label</field>
<field>privacy_label</field>
<field>privacy_linking_text</field>
<field>terms_label</field>
<field>terms_linking_text</field>
<field>signup_button_label</field>
<field>signin_message</field>
<field>signin_linking_text</field>
<field>active_form</field>
</fields>
</widget>
</elementor-widgets>
</wpml-config>
As you can see, the config is not very huge, as there are not many fields that actually could get translated. You can only send texts from Elementor Widgets to the WPML Translation Editor if the widgets have editable text fields.
This config I saved at WPML > Settings on the tab "Custom XML Configuration".
After that, the original widgets will need to be edited on the original contents, then the content needs to be saved, and once you open the WPML Translation Editor, the translatable texts should show up.
Anything else, apart from this, is dynamic data coming from the database or is coded directly inside the plugins.
This means ideally, as long as the Listings, their taxonomies are translated, you should see translated content on translated widgets and anything else, needs to be translated with WPML > String Translation.
To make the listings translatable, go to WPML > Settings > Post Types Translation and set "Listings (at_biz_dir)" to "Translatable only show translated items".
To make the listing taxonomies translatable, go to WPML > Settings > Taxonomies Translation and set the following entries to "Translatable only show translated items":
- Listing Directory (atbdp_listing_types)
- Listing Categories (at_biz_dir-category)
- Listing Locations (at_biz_dir-location)
- Listing Tags (at_biz_dir-tags)
Further, you will need to go to WPML > Settings > Custom Fields Translation
and click "Show system fields". Here you will find many listing-related fields that need to be set to "Copy" if you want to copy their value over to the translated listing, or they need to be set to "Translate" if their field values require a translation.
These are global fields that control each listing. The fields should be adjusted before translating the listings.
Usually, the author of the plugin can define a default config for all post types, taxonomies, and custom fields in a wpml-config.xml file, but as this is not the case here, each field will need to be configured manually.
If you do not plan to translate the listings and their taxonomies, please let me know.
Finally, I suggest you go to WPML > Translation Dashboard > Other texts (Strings) and enable the option to auto-detect strings on Frontend:
"Untranslated strings that I encounter on front-end while logged in (recommended)", and in this case, I recommend that you also enable the option "Also register strings from the website's back-end".
If you now visit translate pages or listings, the strings that require translation at WPML > String Translation will be registered automatically.
On our test site, I imported the demo content and used a dummy engine to translate all listings, taxonomies, and strings coming from the plugins.
The auto-detection feature of WPML did in this case, not yet capture all the strings - there might be various reasons for that, for which each string would need to be investigated closely inside the code of the plugins.
Suggestion:
Go to WPML > Theme & Plugin Localization and scan the following plugins for new strings:
- Directorist - Business Directory Plugin
- Directorist AddonsKit for Elementor
Then translate newly registered strings at WPML > String Translation.
In my sandbox, you can currently review a page that includes all custom Elementor widgets of the plugin and is mostly translated:
hidden link
Some exceptions:
- Add Listing Form
The strings are not part of the widget and are not registered if I scan the plugins for new strings. The reason must be that these strings are not coded properly.
If this widget were coded in the same way as the login/signup form widget, we would be able to translate those strings with the WPML Translation Editor.
There is sadly no workaround for that, as once I try to translate strings of this widget with WPML > String Translation, the strings disappear on the translated widget.
- All Locations and other dynamic widgets
This widget displays the translated Locations, but it does not include the count for each translated listing. The widget's code would need to make use of WPML Hooks to check for translated listings and display them properly.
- Search form
Not usable in a second language
Furthermore, the plugin by default uses shortcodes to, for example, display all listings in pages. This also does not work. The shortcodes are not displaying the translated listings.
These issues might only be solvable by implementing compatilbity code for WPML inside the plugin, or the author might consider including actually all "Add listing" form fields inside the Elementor widgets, instead of loading them directly from the plugin's code.
We can offer assistance on this matter, but it would be ideal if you first forward this message to the author and ask if there is any interest in making the plugin and its widgets compatible with WPML.
The author will need to make use of the following hooks to make the plugin compatible with WPML:
https://wpml.org/documentation/support/wpml-coding-api/wpml-hooks-reference/
We can offer guidance on this behalf if the author is interested in making the plugin compatible with WPML.
The author can fill out this form if there is any interest:
https://wpml.org/documentation/support/go-global-program/
Also note that the author has their own WPML Compatilbity Addon which currently seems not to work as expected.
Example:
The Dashboard shortcode shows complete translations on a translated page, but the All Listings shortcode does not.
After all, there are too many issues that I could solve in one support ticket.
I hope for your understanding.
|
