Forum Replies Created

Viewing 4 replies - 1 through 4 (of 4 total)
  • Do you have a real life example for this case?

    Yes, an example :

    A Microsoft Excel course is given in two languages. Same syllabus, price, category, tags etc, but different class schedule, materials (handbook, exercise files, etc). Tracking them with different SKUs make sense, while still allowing visitors (and search engine) to be able to switch languages.

    – Introduction to C++ in English
    – Introducción a C++ in Spanish

    You’re right, one way of doing it would be two different products, two different SKUs, each translated (so 4 posts).

    But others could/would choose to have only the Spanish version offered on the Spanish side (while being able to stay on the same product when switching languages).
    Imagine this store has 5 languages and offers this same guide (course?) in 5 languages. 5 different products translated in 5 languages would require 25 posts (and prevent visitors from finding another version by simply switching language). That would fill the store with XXX guide in XXX language, which would render navigation quite cumbersome.

    Furthermore, WPML also allows to match languages with currencies, creating even more need (for some stores) for such flexibly with translation.

    In short, your use case is 100% valid and probably the most common, but, in my humble opinion, should not be considered “default/normal” to the extent of overriding the “Allow duplicated SKU” setting without the WPML-aware “extra mile” option described above.

    Currently you can create a translation with the same SKU via WP admin without the option “Allow duplicated SKU” checked, the same operation is not possible via the REST API. Either way, this should be consistent.

    Agreed ??

    • This reply was modified 1 year, 4 months ago by verbalpixel.

    Hello @alexodiy and @luk100r,

    But I would not consider a translation as a duplicated SKU, of course it has the same SKU.

    @luk100r

    A word of caution on this matter: while @luk100r would understandably not have different SKUs for their product translations, other stores would.

    Using Woocommerce, WPML and Easy Auto SKU Generator for WooCommerce, stores may/should have different SKUs for certain translated product/services that are indeed different product/services but are the translated version of each other (like a course available multiple languages, a technical book with one product per language, etc.).

    This would affect the creation of products (using REST, translation, editor) but also features like the “bulk regenerate SKUs”.

    I would recommend either:

    • keeping the behavior as is (as expected, and compatible with the various translation plugins currently on the market or that might be released in the future) by requiring the “Duplicate SKUs” to be enabled, with some documentation/explanation on this setting’s implication on translated products
    • or going the extra mile for WPML specifically and, when a duplicate is encountered while “Duplicate SKUs” is set to false, checking if the duplicate is a translation of the product and that the translation setting of _sku in WMPL is set to “Copy” or “Copy Once” (and not “Translatable”) before allowing that duplicate SKU
      See: https://wpml.org/forums/topic/different-sku-for-different-languages/ for this setting

    Hello @hitendra-chopda

    Could you send us an update on this?

    Could you edit these $product->is_type() checks to be less restrictive? Could you exclude unwanted product types instead of specifically including some (will be compatible with most plugins adding product types to Woocommerce)?

    Regards,

    Hello,

    In 1.9, there are now several IF/THEN statement that enable Product Attachment for WooCommerce for “simple”, “variable”, and “grouped” product types only.
    Search for new occurrences of $_product->is_type here: https://plugins.trac.www.ads-software.com/changeset?sfp_email=&sfph_mail=&reponame=&new=2511256%40woo-product-attachment&old=2501750%40woo-product-attachment&sfp_email=&sfph_mail=#file1

    This “broke” the plugin upon update for a customer using it along with WooCommerce Bookings (where $product->is_type( ‘booking’ ))

    @hitendra-chopda: could you edit these $product->is_type() checks to be less restrictive? Could you exclude unwanted product types instead of specifically including some (will be compatible with most plugins adding product types to Woocommerce)?

    @brandaan:
    Is the type of your affected product other than simple, variable or grouped? If yes, you may want to revert to 1.8 and post your product type here ??

    • This reply was modified 3 years, 10 months ago by verbalpixel. Reason: minor grammar edits and text clarification
Viewing 4 replies - 1 through 4 (of 4 total)