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.

Our next available supporter will start replying to tickets in about 2.63 hours from now. Thank you for your understanding.

This topic contains 6 replies, has 2 voices.

Last updated by nicolasB-29 3 years, 10 months ago.

Assigned support staff: Yvette.

Author Posts
August 17, 2016 at 11:51 am #1006766

nicolasB-29

Why is it possible to change the shipping class in the translated product ? why is it not locked like other product specific attributes ?

August 17, 2016 at 10:26 pm #1007931

Yvette
Supporter

Languages: English (English ) Spanish (Español )

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

Hello.

Most of the locked fields are data that you will find in the post-meta table and is data considered crucial to maintaining data integrity for pricing considerations on a paricular product.

Classes is technically a product taxonomy and the associated information is held in different tables (e.g. wp_terms, wp_term_taxonomy, wp-term_relationship). It is used for grouping products but not for anything integral like pricing.

Does this answer your question sufficiently?

August 18, 2016 at 2:04 pm #1008991

nicolasB-29

i understand the technicals, but product attributes are also a taxonomy and they are also locked. Furthermore i do consider the shipping class a crucial element of product pricing integrity, particularly since changing the shipping class per language does not make sense.

August 18, 2016 at 11:43 pm #1009754

Yvette
Supporter

Languages: English (English ) Spanish (Español )

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

Variable attributes are protected as they are directly related to pricing. This is why they are protected. And I am aware that shipping classes are used by shipping methods which can affect pricing.

I´ve forwarded your question to a senior colleague who can weigh in with some more insights for you on this apparent inconsistency. Perhaps even provide a good example where a shipping class per language might even make sense.

On a more actionable note - are you only looking for clarification on architectural decisions from development? or is your aim to create a feature request that these fields be locked?

August 19, 2016 at 2:48 pm #1010825

nicolasB-29

one of the most toilsome problems in i18n wordpress (don't worry this applies to all plugins) is the difficulty by non-technical personell to maintain content, because the content duplication can be irritation. from my perspective the locking of content which should not be translated seemed like a very good solution to moderate these problems.

furthermore. i had severe problems with the translation of shipping classes, it seems like i mistakenly created shipping classes NOT in the primary language (another thing which shouldn't be possible in my opinion) as a result i was not able to repair the shipping calculation for a number of classes, i had to recreate all of the shipping classes and redo all zones. (all troubleshooting and support fix buttons didn't work)

August 20, 2016 at 3:05 pm #1011970

Yvette
Supporter

Languages: English (English ) Spanish (Español )

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

I can appreciate your need to hide this field then!

I wonder if you can use CSS to "hide" the field by somehow adding a new class to the input field (see image).

Setting the directive to "visibility: hidden" when the language is not the default language might achieve what you need. Of course you would have to maintain the changes each time your upgrade your plugin.

It´s just a thought.

But as a more actionable item, I can list your ticket as a feature request for consideration by the development team. While there is no guarantee on when/if the request will be implemented, there is at least this vehicle available for communication.

August 20, 2016 at 3:18 pm #1011986

nicolasB-29

thanks, but i still would be curious to know what use cases exist to do different shipping classes per language, i think this logic should be handled by the shipping destination