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.