Product Options Fields Not Multilingual

[Phil]

Hello,

all is said in the title :-)

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

Phil.

[Dmitry Andrejev]

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.

DA.

[Alexander Obuhovich]

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

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

[Phil ..:: domicilis.biz ::..]

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

2010/3/16 Alexander Obuhovich <aik....@gmail.com>:

[Alexander Obuhovich]

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

[Phil ..:: domicilis.biz ::..]

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 <aik....@gmail.com>:

[Dmitry Andrejev]

Hi Alex,

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

Phil, would you please describe in more details.

Thanks.

DA.

[Alexander Obuhovich]

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.

[Phil ..:: domicilis.biz ::..]

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 <aik....@gmail.com>:

[Dmitry Andrejev]

Yes, Phil,

It should be the case of course.

DA.

[Phil ..:: domicilis.biz ::..]

ok, thanks !

2010/3/16 Dmitry Andrejev <dand...@gmail.com>:

[Dmitry Andrejev]

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.

DA.

[Phil ..:: domicilis.biz ::..]

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 <dand...@gmail.com>:

> To unsubscribe from this group, send email to
> in-portal-dev+unsubscribegooglegroups.com or reply to this email with the
> words "REMOVE ME" as the subject.
>

[Alexander Obuhovich]

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.

[Dmitry Andrejev]

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?

DA.

[Alexander Obuhovich]

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

[Dmitry Andrejev]

Actually I agree with Alex.

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

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

DA.

[Phil ..:: domicilis.biz ::..]

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 <dand...@gmail.com>:

[Alexander Obuhovich]

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 discussion.

[Phil ..:: domicilis.biz ::..]

you are right, nothing else to add.

2010/3/26 Alexander Obuhovich <aik....@gmail.com>:

[Alexander Obuhovich]

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

[Phil -- wbtc.fr --]

I'd need it :)

your plan seems good, nothing to add.

2011/3/13 Alexander Obuhovich <aik....@gmail.com>

[Alexander Obuhovich]

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

[Dmitry A.]

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

DA

[Alexander Obuhovich]

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. <dand...@gmail.com> wrote:

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

DA

[Dmitry A.]

Phil, any work on this?

DA

[Phil -- wbtc.fr --]

I didn't coded anything, and I still believe this would be usefull, because having standard field ML and not other ones isn't very... practical

2011/3/31 Dmitry A. <dand...@gmail.com>

[Alexander Obuhovich]

Ping to Dmitry.

Summary of discussion:

1. add phrase support to option name (when text is escaped with "!" then it's a phrase, e.g. "!lu_OptionName!"; this way no upgrade script needed)
2. add phrase support to option values of radio/select/multiselect options (when text is escaped with "!" then it's a phrase, e.g. "!lu_OptionValue!"; this way no upgrade script needed)

[Dmitry A.]

Hi Alex,

Thanks for summarizing, yes I agree and believe we should create a task for this and address it in In-Portal 5.3.x branch or sooner (should go in icebox for now anyway).

DA

[Alexander Obuhovich]

Here is the task: http://tracker.in-portal.org/view.php?id=1365