[Gtranslator-devel] Re: Some usability comments on gtranslator 0.39

[Simos Xenitellis <simos74 gmx net>]

On 5 Oct 2001, Fatih Demir wrote:

> On Fri, 2001-10-05 at 01:24, Simos Xenitellis wrote:
...
>     Some terminology (since I do not know the proper one) of the windows of gtranslator.
>
>     -------------------
>              |        |
>      message |english |
>      table   |box     |
>              |________|
>              |        |
>              |local   |
>              |box     |
>              |        |
>     ------------------|
>
>
> Well, almost the same like me/we are using as developers -- the local
> box is named translation box (trans_box in the code) ,-)
>
>
>     Here it goes:
>
>     1. User scenarios
>     One user scenario is to have the message table unordered so that all translated/untranslated/fuzzy messages
>     follow the original po order. That is, no grouping.
>     However, different colors help you distinguish which is which.
>
> Hm, you mean the grouping is not a good solution? I like it, there are some small problems with it but these can be solved though (Kevin ,-)).
>
>     Special shortcuts allow you to go to the
>     	- next fuzzy
>     	- next untranslated
>     	- next fuzzy or untranslated
>     	- next message (any type of message, just for completeness)
>
>
> You mean keyboard shortcuts? There are all present currently (except the
> 3rd case -- but something like that could be integrated); if we
> would/could find some icons for these cases I'd be happy to add such
> buttons, menu entries .-)

Yes, that is keyboard shortcuts.

>
>
>     Benefits
>     	- keeps "vi" translators happy...
>     	- help to identify from previous/next messages what the current message is about.
>
>
> Hm, you mean something like a more contextual view? That's a bit hard to
> do: how to integrate something like that in the GUI? The messages table
> isn't mandatory (you can turn it off in the prefs to save memory + CPU
> time), even for people without the messages table all important elements
> should be visible.
>
> If you can provide me a GUI-al idea how to do contextual views / what
> you wanted to see for an example GUi element en detail I might be a bit
> more enlighted ,-)

Some programs offer contextual view by showing the respective .c source
code of the current message. In some cases this is useless since
translated messages are sometimes grouped together in special .c files.
What I mean is that the order of the messages in the .po file is typically
the same with the order they appear in the source code. Thus, if messages
are shown in their actual (as stored in the .pot file) sequence and not
grouped together, it would help to discern what a message should mean from
the previous and next messages to it.

If you need to translate
	msgid "Stones"
you would put "stones" as in the object.

If it was
	msgid "Stones"
	msgid "Mines"
	msgid "Glines"
you would know by the "context" that these are GNOME games.

>
>
>     For example,
>     	if the current message is "Lower window", it can be translated as "Lower the window" or "The lower window".
>     	If physically next/previous messages are there, one can understand from "Raise window" which of the two options are 	needed.
>
>
> kabalak is currently thinking about something like a popup element for
> the prev./next messages contents.. Maybe too crazy?

As long as they do not distract the translator. Especially, they should
not steal the keyboard focus.. :)

>
>
>     The existing scenario with the three groupings of the messages is also good to keep.
>     2. Initial contact
>     When one loads a .po file in gtranslator, a message is chosen and shown in the english/local boxes.
>     However, it is not highlighted in the message table. This is not intuitive.
>     The first message of the message table should be highlighted and shown.
>
>
> Ha, good to hear that the messages table is welcome .-)
> There's a problem I'd like to solve a logical dis-function of the
> messages table currently: the messages are inserted in reversed order
> into the messages table -- the last message first, the first at last.
> Therefore you won't see it if the first message is marked in the table
> (it should scroll, but I think, there was a problem with the focusing of
> the table, Kevin?)
>
> If you scroll fully down to the first message you will see that the
> first message is physically really marked -- that's a problematic issue
> of the table we should fix. If we would insert the messages in the right
> order (first - first, last - last), then this won't be an issue at all
> as the marking is done and you'll probably see then the marked first
> message in the table .-)

ok, this explains the order issue and why when you press "Next" it goes
backwards, to the previous message.
Isn't there an option to "append at the end" of the list?
It looks that the entries are put at the beginning of the list.

>     3. Keyboard shortcuts
>     The "Next untranslated" and "Next fuzzy" commands go backwards.
>
>
> Uhm? They ought to go backwards if necessary -- the next fuzzy message
> could be the (example!) 13th message and you're at the 475th message: in
> this situation the next fuzzy is at 13, and therefore gtranslator moves
> to there.

Hmm, suppose the list is like this
	one
	two
	three
	four

and "three" is highlighted. When I press "Next", message "two" is
highlighted. This is not I would personally expect to happen.
As you explained above, it's a "workaround" to the problem of having the
messages put in the wrong order, first message in .po file as last in the
list.

>     This is not intuitive. They should go forwards with respect with what is shown in the message table and
>     the current message should be automatically highlighted and sufficiently visible in the message table.
>
>
> I was thinking about adding prev. / next fuzzy, untranslated navigation
> items to ease this situation a bit but would you really want to miss the
> ability to cruise through all untranslated or fuzzy messages with only 1
> shortcut (Alt+U/Z)?
>
> The problem with the messages table was stated by me already above --
> it's a bug in the table which results in usability problems at the last
> consequence.

ack.

>
>
>     The keyboard focus can be set in either the message table, the english box or the local box.
>     When it is in the local box, the Ctrl-N/Ctrl-P accelerators do not seem to work when
>     they are associated with Next/Previous.
>
>
> Hm, yes the navigation shortcuts are captured by an own gtranslator
> key_press handler which does await the hardcoded  standard navigation
> keys Ctrl+Arrow Keys. As this handler is bind to the text boxes you
> can't use Ctrl+N/P while being in them, outside they will probably work
> as gtranslator's keyhandler isn't binded to the other widgets (yet).
>
>
>     This is very strange, if you associate with e.x. Ctrl-O, they work.
>     But not with Ctrl-P/Ctrl-N. Other accelerators work ok.
>
>
> Right, I tried it now.. Must say that this is quite weird for me.. Hm,
> aren't the Ctrl+Arrow Keys intuitive for navigating through the
> messages?! I could enhance the keyhandler to also accept the Ctrl+P/N
> keys but that would be a hack -- if you want this, I'll do it. No
> problem..

If Ctrl-P/Ctrl-N are available outside the "local box", then they should
be available in the "local box". It's a law in HCI :) (human-computer
interaction).
Perhaps these e-mails should be CCed: to gnome-i18n for a second thought.

>     Ctrl-LeftArrow/Ctrl-RightArror: they move to the previous physical message, irrespective
>     of what is shown in the message table.
>     They should follow the message table, and Ctrl-RightArrow should go downwards on the table, Ctrl-LeftArrow upwards.
>
>
> Again a pointer to the table bug -- if the bug is gone away, this will
> be working normal .-)
>
>
>     Ctrl-UpArrow/Ctrl-DownArrow duplicate the usage of the left/right arrows.
>     Again, the down arrow moves upwards to the list of messages.
>
>
> Yes, that's the reversed logic problem -- if the logic/insertion method
> is the "right way 'round" it'll move into the right direction ,-)
>
>
>     Ctrl-Shift-LeftArrow/Ctrl-Shift-RightArrow: These are used to select from the current position until the begining/end of text.
>     The Shift button is currently ignored, thus it works like Ctrl-LeftArrow/Ctrl-RightArrow.
>
>
> Oh yes, this is really due to my custom key_press handler. Would you
> file a bug for this on
> http://bugzilla.gnome.org/enter_bug.cgi?product=gtranslator ? This is
> definitely a heavy bug.

Just reported it.

Thanks again,
Simos Xenitellis