Child pages
  • Making a better interface for multilingual field usability
Skip to end of metadata
Go to start of metadata

Imported from:

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

Related Tasks

INP-684 - Getting issue details... STATUS


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

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

    On Mon, Mar 15, 2010 at 6:26 PM, Phil ..:: ::.. <

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

    2010/3/15 Alexander Obuhovich <>

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

    On Mon, Mar 15, 2010 at 8:07 PM, Phil ..:: ::.. <

  5. allright, I like this idea :)

    2010/3/15 Alexander Obuhovich <>

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


    On Mon, Mar 15, 2010 at 1:20 PM, Phil ..:: ::.. <

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

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

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


    On Wed, Mar 17, 2010 at 3:39 PM, Phil ..:: ::.. <

  10. 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?


    2010/3/18 Dmitry Andrejev <>:

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

    On Thu, Mar 18, 2010 at 9:20 PM, Phil ..:: ::.. <

  12. 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 <>:

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

    On Fri, Mar 19, 2010 at 4:46 PM, Phil ..:: ::.. <

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

    2010/3/19 Alexander Obuhovich <>:

  15. 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?


    On Fri, Mar 19, 2010 at 11:30 AM, Phil ..:: ::.. <

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

  17. About grey hints; just go there : 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

    2010/3/20 Alexander Obuhovich <>:

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

    On Sun, Mar 21, 2010 at 12:18 AM, Phil ..:: ::.. <

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

    2010/3/21 Alexander Obuhovich <>:

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

    On Sun, Mar 21, 2010 at 12:41 PM, Phil ..:: ::.. <

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

    2010/3/21 Alexander Obuhovich <>:

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

    On Sun, Mar 21, 2010 at 1:13 PM, Phil ..:: ::.. <

  23. 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 <>:

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

    On Sun, Mar 21, 2010 at 3:51 PM, Phil ..:: ::.. <