Child pages
  • [in-commerce] Product Options Fields Not Multilingual
Skip to end of metadata
Go to start of metadata

Imported From:


all is said in the title (smile)

I've tried labels and even "inp2:" html, but neither works, and this lasts from the very first versions of In-Portal.

Related Tasks

MINC-100 - Getting issue details... STATUS


  1. Hi Phil,

    Yes, this is true - they are not.

    We'll be reviewing some additions to In-Commerce in a close future and this
    might be one of them.

    Thanks for pointing out.


  2. Maybe this all can be done, since we convert option storage method to xml,
    maybe in 5.2.0 release.

  3. Will this version include an update system for actual products catalog?

    2010/3/16 Alexander Obuhovich <>:

  4. If you mean product price update directly from products list, then it will
    be available in 5.1.0.

    On Tue, Mar 16, 2010 at 1:14 PM, Phil ..:: ::.. <

  5. well, I wasn't expecting a so great improvment, really great !!

    no, I was talking about the update of customers who are actually in
    v50x and whom DB have a lot of product options.

    2010/3/16 Alexander Obuhovich <>:

  6. Hi Alex,

    I think Phil meant different functionality - not the one you
    are referring to.

    Phil, would you please describe in more details.



  7. That's no improvement. Custom fields were multilingual by default all the
    time, since 4.x release. Maybe you've haven't seen them that way. New
    "Multilingual" field was added to them to make custom fields like dropdowns
    have same value for every language.

    On Tue, Mar 16, 2010 at 1:21 PM, Phil ..:: ::.. <

  8. Alex,

    excuse me but in this topic we are talking about product options
    field, and not custom fields :) I've kept separate discussion in order
    not to mix every subject.

    Dmitry, I was asking if users prior to "xml product's options"
    versions will be able to upgrade to the new  xml version, just by
    updating in-portal?

    2010/3/16 Alexander Obuhovich <>:

  9. Yes, Phil,

    It should be the case of course.


    On Tue, Mar 16, 2010 at 6:42 AM, Phil ..:: ::.. <

  10. ok, thanks !

    2010/3/16 Dmitry Andrejev <>:

  11. Just refresh the memory - we need to add ability to specify and properly
    show translated Language Label in Product Option Name.

    Currently it'a a plain text. I guess we can use + before label to identify
    plain text values approach here.

    Phil please correct me if this is what you wanted.


    Oan Tue, Mar 16, 2010 at 6:52 AM, Phil ..:: ::.. <

  12. that's it, absolutly :)

    - it'd be plain text as standard, or a label if "+" is before the value.
    - same thing for option name ;-)

    2010/3/25 Dmitry Andrejev <>:

  13. Plus means different things in different places. For example in custom field
    value list + is used to specify NOT label, but simple text. Here you propose
    it to mean opposite :). This way after upgrade all existing options will
    work as untranslated labels.

    On Thu, Mar 25, 2010 at 11:26 AM, Phil ..:: ::.. <

  14. I meant to say let's use + to recognize plan text ones. During the upgrade
    we can change all to have + or something like that?


  15. Can't predict if users will be too happy about that, but we'll see once this
    will be released.

  16. Actually I agree with Alex.

    Imagine you have to put + every time you add/edit an option - no too

    Alex, what other options we have here from the technical point?


  17. why not using "+" to indicate a lang label?

    In 503 (don't know if there's another version to test for this topic),
    the option name and option values are displaying the same way using
    "+" or not (not to be confused with custom product fields behaviors,
    where + override lang).

    2010/3/26 Dmitry Andrejev <>:

  18. We should use same standard in all places and not to invent something new on
    each form. If we say that "+word" is word and "label" is label, then this is
    site-wide rule. This way user have no need to think if he needs to put "+"
    here or there or not.

    I actually propose same interface as in new translatable field design

    On Fri, Mar 26, 2010 at 7:51 PM, Phil ..:: ::.. <

  19. you are right, nothing else to add.

    2010/3/26 Alexander Obuhovich <>:

  20. So, we need it or not?

    In case if need it, then here is the plan:

       1. add "+" to all option values during upgrade
       2. consider option value a phrase, when there is no "+" in the front

    On Fri, Mar 26, 2010 at 10:27 PM, Phil ..:: ::.. <

  21. I'd need it :)

    your plan seems good, nothing to add.

    2011/3/13 Alexander Obuhovich <>

  22. We'll just wait our another community member to vote on task creation here
    we're finished.

  23. Yes, I believe we SHOULD create a task for this and address it in the future
    (not priority thought).


  24. Yes, please proceed with the task then. I've tried to create suitable
    feature description (in my previous post) so you could easily use it as base
    for task creation.

    On Mon, Mar 14, 2011 at 12:20 AM, Dmitry A. <> wrote:
    > Yes, I believe we SHOULD create a task for this and address it in the
    > future (not priority thought).

    > DA