Imported from: http://groups.google.com/group/in-portal-design/browse_thread/thread/b8547a2fcd4cc0a1#
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
24 Comments
Phil Banks
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>
Alex
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 ::.. <
Phil Banks
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>
Alex
No, editing forms of course, for example link suggestion page.
On Mon, Mar 15, 2010 at 8:07 PM, Phil ..:: domicilis.biz ::.. <
Phil Banks
allright, I like this idea :)
2010/3/15 Alexander Obuhovich <aik.b...@gmail.com>
Dmitry Andrejev [Intechnic]
Yes, I like this idea for both Admin and Front End.
DA.
On Mon, Mar 15, 2010 at 1:20 PM, Phil ..:: domicilis.biz ::.. <
Andrew Kucheriavy [Intechnic]
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?
Phil Banks
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>
Dmitry Andrejev [Intechnic]
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.
On Wed, Mar 17, 2010 at 3:39 PM, Phil ..:: domicilis.biz ::.. <
Phil Banks
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 <dandre...@gmail.com>:
Alex
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 ..:: domicilis.biz ::.. <
Phil Banks
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.b...@gmail.com>:
Alex
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 ..:: domicilis.biz ::.. <
Phil Banks
your idea :)
2010/3/19 Alexander Obuhovich <aik.b...@gmail.com>:
Dmitry Andrejev [Intechnic]
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.
On Fri, Mar 19, 2010 at 11:30 AM, Phil ..:: domicilis.biz ::.. <
Alex
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 Banks
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.b...@gmail.com>:
Alex
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 ..:: domicilis.biz ::.. <
Phil Banks
"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.b...@gmail.com>:
Alex
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 ..:: domicilis.biz ::.. <
Phil Banks
2010/3/21 Alexander Obuhovich <aik.b...@gmail.com>:
Alex
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 ..:: domicilis.biz ::.. <
Phil Banks
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.b...@gmail.com>:
Alex
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 ..:: domicilis.biz ::.. <