Wpml Pro

0 views

Skip to first unread message

Oliverio Gallman

unread,

Aug 3, 2024, 1:01:52 PM8/3/24

to houbitentyou

Hi @aaronjpitts
Thank you so much, it works I was confused a little bit where is wpml_user_id and wpml_key.
But I found. As other packages with .env changes vagrant reload --provision is required.
Thank you again

Hi Bricks team,
we are working on several project a year that requires WPML. (80% of our website are bilingual). We see that WPML is on the roadmap and we understand that you have a lot of stuff to work on with hundreds of request!

Hi @websalia, we are completing a project using WPML and Bricks - launching thursday. (no ecommerce). There is no major issue. We are manually translating each post (not using WPML advanced translation editor).

I am building a multilingual site with WPML. The header has been handled very well, as Bricks+WML are showing the proper menu in each language. But I need to translate a small text on the header manually, and I would like to do it via a condition.

Insert this PHP code into your functions.php and then you will have the ability to select Dynamic data > WPML Language Slug in your condition settings. From there, use the language slugs to show or hide the element.

2 - Then I have edited my footer template, and add three text blocks. One is for English, another one for French and a last one for Catalan. Catalan is the main language, and the other two are translations.

Based on the last screenshot, the issue may be that the conditions are set to OR instead of AND. Try hitting the + button at the bottom of the first condition and recreate the second condition (wpml_language_slug != fr) and then remove the last condition.

Could you try putting wpml_language_slug inside of a Basic Text element to ensure that it is working properly? Additionally, you could try switching the statements to check if wpml_language_slug == ca

We're creating only one form for the post upload, and I was wondering if there is a field that we can use to enable the user to choose the language that the post will belong to, in such a way the WPML will understand and assign to that language.

I'm not familiar enough with WPML to know how it says what language the post is. There isn't a built in feature in Gravity Forms for you to select the language because it's not core WordPress functionality so it's not something built into the Post Fields.

If WPML simply stores the language type as a custom field in post meta for that post then it will be as simple as using the Post Custom Field, set the correct custom field name and then configure it as a drop down and set the choices so they use values that are WPML friendly.

You'll need to find out from WPML where and how this data is stored. If it's as post meta, whats the custom field name/key and what is the value that is stored. Is it's the language code, name, what exactly. You'll need those details to be able to implement this.

I asked them, and they pointed me to a page that lists the WPML tables.
Then I continued to search on how to insert into those tables, and found this post, which essentially says that this post parameter has to be filled
$_POST['icl_post_language']And then call wp_insert_post($new_post);
Can you guide me how to go on from here?

I already use the gform_post_submission hook in order to add a custom field to the post, and I call wp_update_post at the end of my function, so I thought I'd add that line right before the call to wp_update_post. But I must be doing it wrong, as the language isn't added. Maybe it's too late to add it there? Maybe an UPDATE to that table is due at that stage?

I believe you can add it using the gform_post_submission hook. However, if you are using Gravity Forms 1.6 or later, that hook has been replaced by gform_after_submission and you should now use that instead.

I would like to get this working... Has anyone ever tried doing this... I have users with different languages submitting posts from the front end, and would like to add the wpml language info to it...

I saw some other posts on here where people hadn't switched on the option WPML > Languages > Language filtering for AJAX operations > Store a language cookie to support language filtering for AJAX, but it is on our site and the filtering still doesn't work correctly.

If you check WPML->Settings->Post Type Translation, you will see that "Nanny Ads" are not translatable, Which means that German does not have any Nanny Ads, and of course the search results will always be empty. Check this screenshot hidden link

You will have to configure "Nanny Ads" to be:
- Either: Translatable - use translation if available or fallback to default language
- Or: Translatable - only show translated items
In the second case, you will have to translate all the "Nanny Ads" to German or duplicate them from WPML->Translation Management.
In case you choose the first one, keep in mind that it will work only on one direction(English "Nanny Ads" will appear on German, not the opposite).

This is quite disappointing, as our site is a listing site, which Toolset is supposed to be ideal for and was one of the reasons why we chose Toolset in the first place. However whenever a user creates a listing, it should be viewable and updatable (using Toolset Forms) in all languages. Currently our site is English and German - we had to remove Spanish to reduce complexity unfortunately.

If we set to Translatable or Translatable - Fallback, then editing a listing using Toolset Forms in the "secondary" language (German) does not update the listing in the primary language, and the two languages get out of sync which is unacceptable. (Please feel free to correct me if any statement I have made is incorrect or inaccurate! Perhaps with the current versions of the various plugins, that has changed? We try to always be on the latest version. But as far as I can see my statements are still correct.)

Of course we would be absolutely delighted if this serious design flaw has been corrected with the WPML duplication/translation issue that updates to listings in a "secondary" language are not automatically propagated to or reflected in other languages. ?

Should it work if we set WPML > Languages > Language filtering for AJAX operations > Store a language cookie to support language filtering for AJAX to OFF and leave the Ads (listings) on Do Not Translate?
This option is only useful if there is data that will be queried. If for example, you only have the posts in German, this option will not help with English, and vice-versa.

Regarding WPML, it may seem difficult to use, especially, because it tries to provide a solution for a huge range of use cases from a small website to very big websites. That may be overwhelming. But once, we understand how it works, it becomes simpler.
The best practice with WPML is to translate from the primary language to the secondary languages. And sometimes, it is useful to duplicate instead of translating(which is helpful for SEO reasons). But it is always a one-way direction. If the original post is updated, the modification is propagated to the duplicate, but not in the other direction.

I can't really say what option to choose for WPML(translatable or not, with fallback or without), that depends on the project use case. I would say, that duplication is probably the best solution, but it will need custom code to be implemented. And If you desire to update the duplicate with CRED forms and propagate the modification to the original post, it will need additional custom code.

Basically, the translation mode to choose will depend on your use case, so depending on what you expect to have, I can suggest what to do. Currently, I can see that the search form is working for both languages. German only contains 2 posts right now.
So, let me know what you would like to have in terms of functionality(need German posts to be also viewable in English and vice-versa, etc.) and I'll suggest what to do.

Our goals are very straightforward. We want to use Toolset and WPML as our preferred plugins to handle most of our site and to avoid having to be a PHP programmer to get a decent site up and running, which is functional and easy to use.

More specifically:
1) When creating Ads, users should be able to view and edit their Ads in any language.
2) The newly created Ads should be instantly available in all languages. We only have one text field which doesn't need translation, the rest of the fields are taxonomies which are already translatable, or numbers or dates, which require no translation. (Please note, this works perfectly when Do Not Translate is selected. Our only problem is having AJAX instant search switched on and having Do Not Translate selected).
2) Any updates performed via Toolset Edit Forms must propagate to all other languages, regardless of whether they are primary or secondary.
3) The search functionality must find all results, regardless of whether they primary or secondary, for the same reasons as in point 2: the taxonomies are translatable and numbers and dates need no translation.

NICE TO HAVES once 1, 2 and 3 are given:
4) If possible, not to have to create (in my opinion superfluous) duplicates of the content. From a database point of view, this is a very strange practice to have to duplicate everything (and triplicate, quadruplicate etc for each additional languages), rather than just translating labels etc.
5) AJAX "instant" search should work, regardless of language

Regarding (1), let's first see how we can view ads in any language with WPML. The possible ways are:
1. Configure Ads to be translatable with fallback to the original language if no translation is available. But this only works for posts in the default/primary language. Check this article -your-contents/displaying-untranslated-content-on-pages-in-secondary-languages/
2. Duplicate the post to other languages. This needs "WPML Translation Management" activated and configured. And needs to be done from the backend. -your-contents/displaying-untranslated-content-on-pages-in-secondary-languages/using-content-duplication/
To do it automatically, it needs custom code. If you need this feature built into WPML plugin, I'll suggest asking for it here -a-new-feature-for-wpml/
3. Custom code again, by hooking into the actual WP_Query and modifying the "suppres_filters" argument. Check this support forum -wp_query-in-all-languages/