Making a better interface for multilingual field usability

[Alexander Obuhovich]

For now we have two possible interfaces to work with multilingual fields:

• list all on one form
• list only current language field and place language dropdown on top of the form

First solution makes forms really huge, when you have at least 3 translatable fields and 3 languages in system. Second solution slow down translation, since each time language is changed form is refreshed. And if I just want to look on other language translation then I still have to wait for complete form refresh.

I propose another way (see attached image): when we see only selected language field (like in second solution) and we have language tabs above that field, that will allow to switch current language of the field without complete form refresh. Each translatable field (textbox, textarea) will have such language tabs above them. When for example field is required and we doesn't fill it, then appropriate tab will be highlighted in red and will be automatically selected. In case if there are errors on more, then one language, then first tab with error will be selected and moving cursor over problematic tab will display it's error as a hint OR in appropriate area for errors (on form top).

--
Best Regards,

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

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

your tabs really look nice, and it's the kind of functions I'd like to see in many other places in admin !

By the way, where do want to put this? I haven't been able to guess it reading your post :S

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

--
You received this message because you are subscribed to the Google Groups "In-Portal Design & Interfaces Team" group.
To post to this group, send email to in-porta...@googlegroups.com.
To unsubscribe from this group, send email to in-portal-desi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/in-portal-design?hl=en.

[Alexander Obuhovich]

We don't a lot translatable fields right now, but possible places could be:

• section editing (name, description)
• link editing
• product editing

and so on. I propose to make this interface default and also on front-end too.

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

What's the use on front-end? To change global site langage, on the top for example?

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

[Alexander Obuhovich]

No, editing forms of course, for example link suggestion page.

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

allright, I like this idea :)

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

[Dmitry Andrejev]

Yes, I like this idea for both Admin and Front End.

DA.

[ky4ep]

Alex, excellent idea! I've been wanting to do something like this for
a very long time.

several things to consider:

1) I assume they will be switched using Ajax?
2) When translating, it is also useful to see the default language
side by side. OR have other tabs (if empty) automatically show default
language so that it can be translated on the fly
3) It would also be nice to show which tabs have been translated and
which haven't been

Finally, I wouldn't do it for individual fields, it would just be
impractical to work with. I think we should do it for the entire form.

Let's maybe see/discuss a prototype first?

On Mar 15, 5:42 pm, Dmitry Andrejev <dandre...@gmail.com> wrote:
> Yes, I like this idea for both Admin and Front End.
>
> DA.
>
> On Mon, Mar 15, 2010 at 1:20 PM, Phil ..:: domicilis.biz ::.. <
>

> p...@domicilis.biz> wrote:
> > allright, I like this idea :)
>

> > 2010/3/15 Alexander Obuhovich <aik.b...@gmail.com>

>
> >> No, editing forms of course, for example link suggestion page.
>
> >> On Mon, Mar 15, 2010 at 8:07 PM, Phil ..:: domicilis.biz ::.. <
> >> p...@domicilis.biz> wrote:
>
> >>> What's the use on front-end? To change global site langage, on the top
> >>> for example?
>

> >>> 2010/3/15 Alexander Obuhovich <aik.b...@gmail.com>

>
> >>>> We don't a lot translatable fields right now, but possible places could
> >>>> be:
>

> >>>>    - section editing (name, description)
> >>>>    - link editing
> >>>>    - product editing

>
> >>>> and so on. I propose to make this interface default and also on
> >>>> front-end too.
>
> >>>> On Mon, Mar 15, 2010 at 6:26 PM, Phil ..:: domicilis.biz ::.. <
> >>>> p...@domicilis.biz> wrote:
>
> >>>>> your tabs really look nice, and it's the kind of functions I'd like to
> >>>>> see in many other places in admin !
>
> >>>>> By the way, where do want to put this? I haven't been able to guess it
> >>>>> reading your post :S
>

> >>>>> 2010/3/15 Alexander Obuhovich <aik.b...@gmail.com>

>
> >>>>>>  For now we have two possible interfaces to work with multilingual
> >>>>>> fields:
>

> >>>>>>    - list all on one form
> >>>>>>    - list only current language field and place language dropdown on

> >>>>>> in-portal-desi...@googlegroups.com<in-portal-design%2Bunsu...@googlegroups.com>

> >>>>>> .
> >>>>>> For more options, visit this group at
> >>>>>>http://groups.google.com/group/in-portal-design?hl=en.
>
> >>>>>  --
> >>>>> You received this message because you are subscribed to the Google
> >>>>> Groups "In-Portal Design & Interfaces Team" group.
> >>>>> To post to this group, send email to in-porta...@googlegroups.com
> >>>>> .
> >>>>> To unsubscribe from this group, send email to

> >>>>> in-portal-desi...@googlegroups.com<in-portal-design%2Bunsu...@googlegroups.com>

> >>>>> .
> >>>>> For more options, visit this group at
> >>>>>http://groups.google.com/group/in-portal-design?hl=en.
>
> >>>> --
> >>>> Best Regards,
>
> >>>>http://www.in-portal.com
> >>>>http://www.alex-time.com
>
> >>>> --
> >>>> You received this message because you are subscribed to the Google
> >>>> Groups "In-Portal Design & Interfaces Team" group.
> >>>> To post to this group, send email to in-porta...@googlegroups.com.
> >>>> To unsubscribe from this group, send email to

> >>>> in-portal-desi...@googlegroups.com<in-portal-design%2Bunsu...@googlegroups.com>

> >>>> .
> >>>> For more options, visit this group at
> >>>>http://groups.google.com/group/in-portal-design?hl=en.
>
> >>>  --
> >>> You received this message because you are subscribed to the Google Groups
> >>> "In-Portal Design & Interfaces Team" group.
> >>> To post to this group, send email to in-porta...@googlegroups.com.
> >>> To unsubscribe from this group, send email to

> >>> in-portal-desi...@googlegroups.com<in-portal-design%2Bunsu...@googlegroups.com>

> >>> .
> >>> For more options, visit this group at
> >>>http://groups.google.com/group/in-portal-design?hl=en.
>
> >> --
> >> Best Regards,
>
> >>http://www.in-portal.com
> >>http://www.alex-time.com
>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "In-Portal Design & Interfaces Team" group.
> >> To post to this group, send email to in-porta...@googlegroups.com.
> >> To unsubscribe from this group, send email to

> >> in-portal-desi...@googlegroups.com<in-portal-design%2Bunsu...@googlegroups.com>

> >> .
> >> For more options, visit this group at
> >>http://groups.google.com/group/in-portal-design?hl=en.
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "In-Portal Design & Interfaces Team" group.
> > To post to this group, send email to in-porta...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > in-portal-desi...@googlegroups.com<in-portal-design%2Bunsu...@googlegroups.com>

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

Welcome back Andrew :)

2) may we could display default language into the field to translate, in grey color, and it disappears when we clic into the field to translate it

3) good idea too, may we can just play with tab background color

2010/3/17 ky4ep <and...@ky4ep.com>

To unsubscribe from this group, send email to in-portal-desi...@googlegroups.com.

[Dmitry Andrejev]

Hi guys,

Here are my comments on Andrew's notes:

1. Ajax would be nice, but the issue is that if we say we have 1 single Language tab Switcher for the entire Form then we'll have to reload the entire Form including Fields which are NOT multi-lingual. While this is might be good from the Interface point- it might causes some issues with programming it. Alex what do you think.

2. It's going to be a pain to show Primary Translation somewhere  next to the field, just image if it's a TEXTAREA and you have a few paragraphs - simple not space for it. However showing Primary Language value as an actual value for the field complicates things since we won't know on form Save/Submit if value in there is actually translated or is Primary and should not be saved. I think this can be solved with a checkbox (Translated) next to the field...

3. Idea with indication whether fields is translated or not will NOT work if we are using a 1 single Language tab Switcher. This will only work if we have it for each separate field. But I like the idea!

4. Now about 1 single Language tab Switcher. I personally think it's a good idea to have separate Tabs for each Field and not a single one for the entire form or may be teach In-Portal to work with both...

DA.

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

Hello,

1. if we use Ajax, why should we reload all the form? Can't we do what
we want, like switching only concerned field? Why "reloading", instead
of switching? Ajax is perfectly for this kind of tasks, don't it?

2. Again, using Ajax, is it so hard to display in fading grey the
original text, and detect if users enters something else?

3. this indicator could be used to indicate that translation isn't
done at all, or not complete

I'm sure we can do all of these with JS... or I missed something?

Phil.

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

[Alexander Obuhovich]

About ajax all of you are wrong, since no ajax is required: we will have controls for each field on each language, but one one per field will be visible at a time. About detection of changes is it really necessary? Because in case if we change primary translation, then all other translations are marked as changed. I agree with Phil about that.

Of course we use separate tabs for each field, because when we have error in specific field on specific language, then how we should display that, when we don't have language tabs before that field.

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

thank for this language hint "control" :) We can modify form controls
behaviors and do whatever needed, even changing only 1 field in the
whole form, right?

About the said problem about the fact that primary language could be
copied into other language if it's shown by default as hint, this is
rather a good thing, avoiding blank fields on front when translation
isn't done yet.

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

[Alexander Obuhovich]

1. - of course
2 - we would not have blank fields, since, when field isn't translated on current language, then translation from primary language is shown automatically. And primary language translation is required for translatable fields marked with "*" on form.

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

2, I was thinking about this feat. then no more obstacle to realize
your idea :)

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

[Dmitry Andrejev]

Can someone do:

1. a prototype of the one whole From for Admin and then for Front

2. list all features (specs) in clear 1,2 ,3 order so we can covert this to task later.

Andrew, do you have anything to add to above discussion?

DA.

[Alexander Obuhovich]

Idea about primary language value in grey in non-primary language field is still a bit unclear. We are using it or not?

• form could consist of one or many controls, that look like (see image from my original post)
• each tab above language will indicate translation status on that language (transparent - have translation, black - selected, red - has error, grey - have no translation) - of course colors are up to designers
• clicking on tab will show field (textbox, textarea, maybe inline fckeditor) on that language
• each field will have independent set of language tabs, that will allow to work with each field individually
• tabs are switched without form refresh or ajax allowing user to look on field value from primary language without interrupting translation process
• when field will contain error, that appropriate tab will be automatically selected upon form will be submitted
• when moving mouse cursor over a tab and that tab's language translation contains an error, then it will be displayed on form top; same when clicking inside problematic field
• upon form submit (in case of error) on any even (non translatable) field all tabs selected will be reset to primary language, except of case we have an error in one the tabs (e.g. I have "en", "ru", "fr" tabs and edit "fr" and after submit I will have "en" selected, because it's primary). Maybe we need to keep selected tab for each field on form refresh, but don't understand how exactly.
  

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

About grey hints; just go there : http://www.facebook.com/ without
being connected, and look into e-mail and password fields (if your
e-mail is entered, just delete it and clic elsewhere).

Alex, your description seems good, as I far as I understand it too,
and I'd prefer 1 and only lang tab on top, this will "lighten" the
admin interface, and won't affect user's productivity, what do you
think?

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

[Alexander Obuhovich]

How about error reporting? How can user guess, that he has error in the field on language that isn't selected.

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

Error reporting will occurs if field is left blank while it's setup as
"required", right?

And what about the situation, when you start to translate in another
lang., and you don't know one of the translation, if we have required
field we won't be able to save partially translated forms... I had the
case, you translate the 2nd lang., you start the third, and because
you can't escape the form, you need to discard all your changes... I'd
prefer to have only required fields for primary language, what do you
think?

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

[Alexander Obuhovich]

There could be several error types, for ex. field translation is too long on one language and normal length on other. About required only translation on primary language will be required as for now.

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

allright then, I've nothing else to add :)

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

[Alexander Obuhovich]

The trick about interfaces is to image what you don't see and especially interface parts, like error messages, that are not visible by default. That's a bug in most designs I've seen, since designers won't leave place for errors.

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

in the actual state of this implemantation, we'll have error on masked
forms visible by changing tab colors, and error in current form like
before, on the right, isn't it?

we could also use CSS, like I've done on some website, to make the
error field surrounding the field in error, do you get what I mean?
this way, error isn't shown on the right, but in the field design
itself. I can provide you an example if you want.

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

[Alexander Obuhovich]

You seem to talk about error style from 4.x versions of In-Portal. In administrative console of 5.x version there is a special area on top of the form to display errors. When user moves cursor over the problematic field, then it's error is shown on form top. Such approach prevents form jumping especially in popups, when error happens.

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

yes, but because of height of "general" pages and the fact that form
top isn't static,I'd suggest something lile attached picture.
This example have been done only by modifying actuall CSS, I think
it's even more user friendly, what do you think?

[Alexander Obuhovich]

You seem to misunderstood something, since form top in static - error is always visible during scrolling. Try product editing form.

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

1- then I'm happy to discover another bug, form top isn't static in
"same window" edit mode, while it is in modal window and popup ones
:-)

2- anyway, what do you think about my design suggestion? this is more
clearer than asking people to mouse over fields, and a red background
is more visible than red field name, don't you think so?

[Alexander Obuhovich]

Field names are red, that noticeable, but why not, let's ask others about that, since I'm not a big designer here.

[Dmitry Andrejev]

Guy,

I think we should stay focused on the Multi-lingual field issue that we trying to work out.

We really need to have a screen before we can proceed to anything, are you agree with me on this?

DA.

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

well, it seems to me this is a part of it:

- tab would appears as Alex shown, on top of form

when an error occurs:
- if it's in the actual tab, I propose to change background of
concerned field (as I shown, using CSS)
- it it's another tab, we change the background color of Alex's tab,
and once we clic, we'll see the concerned field

Alex, I'm ok? Dmitry, seems good for you?

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

[Alexander Obuhovich]

Not on top of the form, but before each translatable field. No central for language selector as now on category edit page.

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

ok, but it means we will have to clic on lang tab belonging to each
field before translating it? I mean will need to clic as much as
there's multilingual field tabs?

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

[Alexander Obuhovich]

It looks that way. If you have better idea how to have central form language selector on top as for now and display specific-language related errors, then please propose it as I don't one right now.

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

The main thing I wanted to escape was the reloading of the whole page to change language, and as we discussed before, this can be easily avoided.

I was thinking about a main tab menu at top of the form, because:
   - tab will stay always visible, then always accessible for changing
   - once we start to fill in a new language, it's rarely we need to have lang1 description with a lang2 url displayed at the same time
   - when you need to fill many fields, you use tabulation, right? the need to clic on a tab between 2 fields would lower the entry process

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

...

[Message tronqué]  

[Dmitry Andrejev]

I see point that is making Phil with TAB as tool for switching between fields, but the problem with having singe Language Tab Switch is that we won't be able to:

a. we would have no way to specify (ie. by highlighting)  which Language of which fields has an error or is Primary.

b. currently we have Drop-down with form Language which is similar to tabs I think... 

It's not I don't like your idea - I am trying to make sure it's practical...

DA.

--
You received this message because you are subscribed to the Google Groups "In-Portal Design & Interfaces Team" group.

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

Hi Dmitry,

I understand your opinion; here are the suggestions I've made:

a. to specify an error, I've proposed a different tab background,
along with a very visible field name background changed to red (or
whatever ^^)

b. Drow down actually reload all page, while we wanted a page with
no reload, and tabs are faster as they need only 1 clic, while drop
down needs too. This seems nothing, but when you need to enter
hundreds of products, i t saves you a lot of time

Phil.

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

[Alexander Obuhovich]

Any changes here? This feature is still needed?

You received this message because you are subscribed to the Google Groups "In-Portal Design & Interfaces Team" group.

[Dmitry Andrejev]

Yes, this definitely needed!

Guys - Phil, Andrew - we have to revisit this again.

DA.

[Phil -- wbtc.fr --]

Here are my ideas, as a personnal revisit :

   a- a top tab's bar show each available lang : en,fr,ru,pl ... Primary lang tab would be on the left, with a darker background color

   b- all fields for all langs are loaded with the page, for direct displaying when clicking on a tab

   c- fields with errors would have a light red background color along with error message (error message in field would even by unecessary, a single "please see error below" at the top would be enough

   d- when clicking on another tab while fields have errors, we stay on the current tab

Please comment me !

Phil.

2010/4/26 Dmitry Andrejev <dand...@gmail.com>

...

[Message tronqué]  

[Alexander Obuhovich]

Back to this discussion after 4 months.

I'm becoming to agree with Phil at some point, since errors from translatable field on any language are redirected back to field on primary language.

For example:

• you have l1_Name and l2_Name fields on form;
• 2nd language is primary;
• in case of error in l1_Name field it will be shown under l2_Name field.

So here is the solution, that should fit our needs without even requiring extra space for additional controls. No new controls added only existing controls will work a bit different:

1. each translatable field will have input controls on all languages, but only one control per field will be visible at a time;
2. dropdown on top (with language list) will affect all translatable fields and will make controls on new selected language become visible (instead of previous current language) without form refresh;
3. top dropdown name will be "m_lang", so it will be remembered as form language once form is submitted;
4. translatable fields should use "inp_edit_box_ml" and "inp_edit_textarea_ml" blocks for this to work;
5. mentioned above blocks needs to be rewritten to support such behavior.
   

We have JavaScript Form class, that tries to fill empty space at form bottom by resizing textarea, so we should trick it and make it assume, that same field on different languages is actual one field, that uses space on form and not all of them will be always visible.


Task: http://tracker.in-portal.org/view.php?id=851

[Phil -- wbtc.fr --]

very good definiton Alex.

We have the ML field problem also in link suggest form, when we submit
the form and a ML field is in error, it show as many input fields as
there is different languages.

Btw I also suggested to extend ML fields, (as reported in
http://groups.google.com/group/in-portal-bugs/browse_thread/thread/5ae549842c7077f6/02a47eeba800c8f1?hl=fr&lnk=gst&q=multilingual+field+suggest#02a47eeba800c8f1,
beginning of the discussion) I wasn't able to have more ML fields, and
I was very sad :S

2010/9/1 Alexander Obuhovich <aik....@gmail.com>:

[Alexander Obuhovich]

That discussion is not related to this discussion.

[Phil -- wbtc.fr --]

you said "mentioned above blocks needs to be rewritten to support such
behavior."
and I add it'd be good if this reformatting also permits to use them
more than twice in suggest form, does this problem isn't belonging to
ml element too?

2010/9/2 Alexander Obuhovich <aik....@gmail.com>:

[Alexander Obuhovich]

Discussion, you've mentioned is about inability to display custom field value more then on one language on suggest link form.

Nope, what I'm about to change it completely unrelated to that issue. If both discussions have "multilingual" word in them, then it doesn't mean, that they are related at all.

[Phil -- wbtc.fr --]

I was associating "rewritting ML code" and the bug I've found.
Ok I've understoud now.

2010/9/2 Alexander Obuhovich <aik....@gmail.com>:

[Dmitry A.]

I think this discussion should NOT be forgotten since we have talked a
lot in here already.

Just to remind to everyone it was about improving Interfaces for
Multilingual Forms in Admin.

DA.

On Sep 3, 2:44 am, "Phil -- wbtc.fr --" <p...@wbtc.fr> wrote:
> I was associating "rewritting ML code" and the bug I've found.
> Ok I've understoud now.
>

> 2010/9/2 Alexander Obuhovich <aik.b...@gmail.com>:

>
>
>
> > Discussion, you've mentioned is about inability to display custom field
> > value more then on one language on suggest link form.
>
> > Nope, what I'm about to change it completely unrelated to that issue. If
> > both discussions have "multilingual" word in them, then it doesn't mean,
> > that they are related at all.
>

> > On Thu, Sep 2, 2010 at 10:49 PM, Phil -- wbtc.fr -- <p...@wbtc.fr> wrote:
>
> >> you said "mentioned above blocks needs to be rewritten to support such
> >> behavior."
> >> and I add it'd be good if this reformatting also permits to use them
> >> more than twice in suggest form, does this problem isn't belonging to
> >> ml element too?
>

> >> 2010/9/2 Alexander Obuhovich <aik.b...@gmail.com>:

> >> > That discussion is not related to this discussion.
>

> >> > On Thu, Sep 2, 2010 at 4:43 PM, Phil -- wbtc.fr -- <p...@wbtc.fr> wrote:
>
> >> >> very good definiton Alex.
>
> >> >> We have the ML field problem also in link suggest form, when we submit
> >> >> the form and a ML field is in error, it show as many input fields as
> >> >> there is different languages.
>
> >> >> Btw I also suggested to extend ML fields, (as reported in
>

> >> >>http://groups.google.com/group/in-portal-bugs/browse_thread/thread/5a...,

> >> >> beginning of the discussion) I wasn't able to have more ML fields, and
> >> >> I was very sad :S
>

> >> >> 2010/9/1 Alexander Obuhovich <aik.b...@gmail.com>:

> >> >> > On Sun, May 2, 2010 at 12:03 AM, Phil -- wbtc.fr -- <p...@wbtc.fr>

> >> >> > wrote:
>
> >> >> >> Here are my ideas, as a personnal revisit :
>
> >> >> >>    a- a top tab's bar show each available lang : en,fr,ru,pl ...
> >> >> >> Primary
> >> >> >> lang tab would be on the left, with a darker background color
>
> >> >> >>    b- all fields for all langs are loaded with the page, for direct
> >> >> >> displaying when clicking on a tab
>
> >> >> >>    c- fields with errors would have a light red background color
> >> >> >> along
> >> >> >> with error message (error message in field would even by unecessary,
> >> >> >> a
> >> >> >> single "please see error below" at the top would be enough
>
> >> >> >>    d- when clicking on another tab while fields have errors, we stay
> >> >> >> on
> >> >> >> the current tab
>
> >> >> >> Please comment me !
>
> >> >> >> Phil.
>

> >> >> >> 2010/4/26 Dmitry Andrejev <dandre...@gmail.com>

>
> >> >> >>> Yes, this definitely needed!
> >> >> >>> Guys - Phil, Andrew - we have to revisit this again.
>
> >> >> >>> DA.
>
> >> >> >>> On Sun, Apr 25, 2010 at 1:21 PM, Alexander Obuhovich

> >> >> >>> <aik.b...@gmail.com>

> >> >> >>> wrote:
>
> >> >> >>>> Any changes here? This feature is still needed?
>
> >> >> >>>> On Thu, Mar 25, 2010 at 1:04 PM, Phil ..:: domicilis.biz ::..
> >> >> >>>> <p...@domicilis.biz> wrote:
>
> >> >> >>>>> Hi Dmitry,
>
> >> >> >>>>> I understand your opinion; here are the suggestions I've made:
>
> >> >> >>>>>   a. to specify an error, I've proposed a different tab
> >> >> >>>>> background,
> >> >> >>>>> along with a very visible field name background changed to red
> >> >> >>>>> (or
> >> >> >>>>> whatever ^^)
>
> >> >> >>>>>   b. Drow down actually reload all page, while we wanted a page
> >> >> >>>>> with
> >> >> >>>>> no reload, and tabs are faster as they need only 1 clic, while
> >> >> >>>>> drop
> >> >> >>>>> down needs too. This seems nothing, but when you need to enter
> >> >> >>>>> hundreds of products, i t saves you a lot of time
>
> >> >> >>>>> Phil.
>

> >> >> >>>>> 2010/3/25 Dmitry Andrejev <dandre...@gmail.com>:

> >> >> >>>>> >> 2010/3/23 Alexander Obuhovich <aik.b...@gmail.com>

>
> >> >> >>>>> >>> It looks that way. If you have better idea how to have
> >> >> >>>>> >>> central
> >> >> >>>>> >>> form
> >> >> >>>>> >>> language selector on top as for now and display
> >> >> >>>>> >>> specific-language
> >> >> >>>>> >>> related
> >> >> >>>>> >>> errors, then please propose it as I don't one right now.
>
> >> >> >>>>> >>> On Tue, Mar 23, 2010 at 2:12 PM, Phil ..:: domicilis.biz ::..
> >> >> >>>>> >>> <p...@domicilis.biz> wrote:
>
> >> >> >>>>> >>>> ok, but it means we will have to clic on lang tab belonging
> >> >> >>>>> >>>> to
> >> >> >>>>> >>>> each
> >> >> >>>>> >>>> field before translating it? I mean will need to clic as
> >> >> >>>>> >>>> much
> >> >> >>>>> >>>> as
> >> >> >>>>> >>>> there's multilingual field tabs?
>

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

> >> >> >>>>> >>>> > Not on top of the form, but before each translatable
> >> >> >>>>> >>>> > field.
> >> >> >>>>> >>>> > No
> >> >> >>>>> >>>> > central
> >> >> >>>>> >>>> > for
> >> >> >>>>> >>>> > language selector as now on category edit page.
>
> >> >> >>>>> >>>> > On Tue, Mar 23, 2010 at 1:55 PM, Phil ..:: domicilis.biz
> >> >> >>>>> >>>> > ::..

> >> >> >>>>> >>>> > <p...@domicilis.biz> wrote:
>
> >> >> >>>>> >>>> >> well, it seems to me this is a part of it:
>
> >> >> >>>>> >>>> >> - tab would appears as Alex shown, on top of form
>
> >> >> >>>>> >>>> >>  when an error occurs:
> >> >> >>>>> >>>> >> - if it's in the actual tab, I propose to change
> >> >> >>>>> >>>> >> background
> >> >> >>>>> >>>> >> of
> >> >> >>>>> >>>> >> concerned field (as I shown, using CSS)
> >> >> >>>>> >>>> >> - it it's another tab, we change the background color of
> >> >> >>>>> >>>> >> Alex's
> >> >> >>>>> >>>> >> tab,
> >> >> >>>>> >>>> >> and once we clic, we'll see the concerned field
>
> >> >> >>>>> >>>> >> Alex, I'm ok? Dmitry, seems good for you?
>

> >> >> >>>>> >>>> >> 2010/3/23 Dmitry Andrejev <dandre...@gmail.com>:

> >> >> >>>>> >>>> >> > Guy,
> >> >> >>>>> >>>> >> > I think we should stay focused on the Multi-lingual
> >> >> >>>>> >>>> >> > field
> >> >> >>>>> >>>> >> > issue
> >> >> >>>>> >>>> >> > that we
> >> >> >>>>> >>>> >> > trying to work out.
> >> >> >>>>> >>>> >> > We really need to have a screen before we can proceed
> >> >> >>>>> >>>> >> > to
> >> >> >>>>> >>>> >> > anything,
> >> >> >>>>> >>>> >> > are
> >> >> >>>>> >>>> >> > you
> >> >> >>>>> >>>> >> > agree
>

> ...
>
> read more »

[Phil -- wbtc.fr --]

it seems we are mixing 2 different topics in this discussion:

- about grouping custom fields in admin pages

- about making custom fields multilingual

ok, may this mix is my fault again :)

2010/10/28 Dmitry A. <dand...@gmail.com>

--

[Alexander Obuhovich]

Nothing is forgotten Dmitry. Me an Phil already have created a task: http://tracker.in-portal.org/view.php?id=851 1.5 months ago (1 Sep 2010).

Phil, no mixing here. We are not talking about custom fields here at all. 

--

You received this message because you are subscribed to the Google Groups "In-Portal Design & Interfaces Team" group.
To post to this group, send email to in-porta...@googlegroups.com.
To unsubscribe from this group, send email to in-portal-desi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/in-portal-design?hl=en.