Quoting Christian Stimming <[EMAIL PROTECTED]>:
Am Samstag, 1. April 2006 16:51 schrieb Josh Sled:
http://asynchronous.org/tmp/encoding-ui.html
I'm concerned about the tedium of clicking through a lot of "Forward"s
to deal with strings one at a time, so I'm assuming a batch/list
interaction. If -- as we hope -- the vast majority of the strings need
only a quick visual confirmation of correctness, then we should present
them all at once to be, well, quickly confirmed.
Absolutely. I don't understand the reason for having one combobox per string.
The reason is that it's /possible/ that a data file has a combination
of multiple encodings. For example, if someone was running gnucash 1.8
is a non-UTF8 locale for a while, entered a bunch of accented characters,
and then later started running gnucash 1.8 in a UTF8 locale and entered
a bunch more accented characters... It's possible the data file has
multiple encodings.
I've seen at least one example of this from a user, so it is NOT a
theoretical problem. It actually does happen.
My suggestion/favorite would be your version #1, but only with the right
column. I expect the user would have only *one* place to choose the encoding,
and this encoding will change all imported strings. So if, at a quick glance,
the strings appear incorrect, the user would choose something differently in
the *single* combobox, until the strings look correct.
In the current setups, it is not clear to me whether the expected action of
the user on seeing "wrong" strings is to click on the topmost combobox or
rather at the combobox in the respective line.
This is why we provide an instruction page.
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
[EMAIL PROTECTED] PGP key available
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
