Translate options with WPML, any progress?

Hi,

I would recommend using string translation functionality and translate existing forms this way.

I went to WPML’s “String Translation” and none of your strings were there.

I then went to the “CPO Options” panel. In the “Multilingual Content Setup” I set the “Make ‘CPO option’ translatable” option and set the system fields _cpo_general and _cpo_suboptions to “Translate”, the rest to “Copy”. I provided translations for all the label and tooltip strings and copied the rest (eg. the slug names, booleans etc).

The form was still not showing.

I went into the product. In the “Multilingual Content Setup” I made all the _cpo system fields to “Translate”. There were no fields that needed translating so I copied all the fields including “Cpo content”, “Cpo enable”, “Cpo calc enable”, “Cpo formula rules enable” and “Cpo main formula”.

The form now appears in the translated product page but everything on it is in the base language EXCEPT from some common options like “None” and “Cut”.

So far after all these hours I am still not seeing any of the translations I have provided in CPO Options.

Have you tested your plugin with WPML and can you please provide some more detailed guidance?

Is your plugin really only built for English?

That would be a pity because it is quite a capable plugin.

No, I have not tested it with WPML. But other users reported they achieved it with that plugin. They said they were using string translation functionality. How exactly? I don’t know.

Also, some other users were using Loco/Polylang and similar functionality.

Alright. I will spend a bit more time on this today and report when I have some progress.

I am concerned because our site (small textile workshop) will be selling yardage goods and we need a calculator in quite a few products. Plus we have some custom products with yardage, colours and additional options all affecting the final cost. Being in Europe, we will end up with at least six languages by the end of the year.

I think, however, you should contact the WPML guys and see what their “Go Global” program is. When I was talking about your plugin to their support, the support person said that in this program they help you make your plugin more translation friendly. Maybe it is worth it for you to chat with them, I hope you do!

Cheers.

Thanks for the suggestion!

You can get started here:

https://wpml.org/documentation/theme-compatibility/go-global-program/#how-do-i-get-started

Final progress.

I noticed that when I copied the system fields from the base language to another, the form styles degenerated and the price stopped updating. Something must be confusing the styles.

The only way that I could get a band-aid reliable result was by removing all the system fields values from the target language and making a new form from scratch with new field names and option values.

This is not actually a sustainable solution because as soon as you have a complex formula with logic, it becomes error prone to maintain. It is even difficult if you have a few dozen products with just a length field because the number of forms you now have to maintain is products * languages. Gets overwhelming quickly.

You really have to make a tutorial with a better method for dealing with languages because this is starting to look like *not multilingual*.

• This reply was modified 5 years ago by aris00.

Probably we will make a detailed tutorial, but for version 5.

I have finally worked out how to translate your forms (not a method that directly involves the WPML facilities) and relies on not selecting the ever so subtle save to DB option.

It took me a couple of days to fully get how your plugin works. I don’t think it should be this hard to get my head around it. Maybe your priority for V5 should be to re-architect this because the save to DB subtlety can so easily be lost on you customers.

Unfortunately, it would would require a fairly lengthy tutorial to communicate all of that information to the general public.

Hi,

Sorry, I don’t get it. What you suggest not doing? Could you clarify this? Thanks!

I have put so much time in this now, and my conclusion that your plugin is not multilingual. I really really hope that you can show me that what I am doing is wrong.

Initially I tried translating the CPO options with WPML but they were breaking the formula so I set them to “Do not make ‘CPO option’ translatable”. The translations I provided did not seem to be used anywhere anyway.

The following is what I do now.

Say I have product in English (EN) with a CPO form with a few fields. I have set up a formula and everything is working fine.

Then I use WPML to add a French (FR) translation of the product. In the multilingual setup for the product I set all the _cpo fields to Translate and Apply. I edit the FR translation and make sure to copy all the _cpo field values from EN to FR. I check that in the front end the FR product is showing a correctly working English form.

I go back to the products list, switch the admin to French, then use the “CPO Builder” link directly from the french product listing to only edit the CPO form.

The field IDs on the FR form are synced to the option IDs from the EN page. Great. I type module label texts, and save but with the “Save to DB?” unticked so I do not overwrite the other data for the module options in the DB.

Now I go to the product front end in French. The labels are in French. I select the various options. The calculation is fine. I add to cart. I go to the cart page. All the options are displayed in English. That’s how they will appear in the customer order. Not good.

Now, I go to the French version of the product and edit the CPO form. This time, I tick the “Save to DB?” for my modules. I go back to the front end. I switch to English. I add the product to the cart. I go to the cart page. The options are now displayed in French. Not good.

So, the options for the product in the cart are displayed using the labels the options had when the modules were saved with the “Save to DB?” option ticked. On top of that, the module editor will flick the “Save to DB?” option on automatically when you are change any of the fields with a yellow triangle. The user may not even realise or really understand what the subtle difference is.

The only way to deal with this is to have different field names for the form of each language so the options in the DB have the strings for each language. However, when you switch language, the cart will still display the product options strings in whatever language you were on when you added it to the cart. Plus you need to readjust the formula to use the language specific field names. Not good.

The setup is too inflexible and fragile in my opinion and you guys need to rethink it. Getting rid of the “Save to DB” concept and utilising the “CPO options” type translations from WPML would be a great start. “Save to DB” is just too much of an internal feature to present to the user in my opinion.

I think that when you “recommend using string translation functionality and translate existing forms this way” is misleading. You should just tell people that your plugin is not ready for multilingual sites or have a document detailing the compromises you need to make in a multilingual setup.

I am really looking forward to your version 5 and I hope that you will take my feedback as constructive. If I am wrong about all of the above I am open to your suggested way of doing things.

• This reply was modified 5 years ago by aris00.

Using string translation functionality is the only proper way for now. Sadly WPML not good enough to utilise this, but other translation plugins seem to be better here. And this way you do not have to copy products

Alright then.

Can be used with some milti-lingual plugins but not with WPML.
According to you, Loco/Polylang are two of the plugins it works with.

Clarifying for other users because I have had a hard time finding enough info out there.