pre-2.0 charset disambig. string review ui mockup

[Andreas Köhler]

Hi,

On Sunday, 02 Apr 2006, 09:05 CEST, Christian Stimming wrote:
> 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. 
> 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.

I think the comboboxes provide increasing granularity. Since the
default encoding will be based on the currently active locale, most
users will be able to just accept the page. If they see that most
strings look garbled, they can change the default encoding at the
top and all strings without an assigned one will hopefully look
better afterwards. Pedantic users can then check every single
word and adjust it accordingly.

The manual option for every word looks necessary to me, because it
was very easy with previous GnuCash versions to mix encodings. This
is the time to fix this problem, centrally.

> > As such, I think the druid can become a single dialog: at the top is the
> > default/presumed value, with a default selection based on the locale,
> > but modifiable by a knowledgeable user.  A the bottom is the table of
> > strings for review and/or fixup.  The "progress bar" becomes the scroll
> > bar through the table, and a single "Ok" at the end affects the changes.

Yes, the conversion can be done on a single page, but a druid that
explains why the heck GnuCash does not simply open the file, will be
helpful too, as mentioned in-channel. There will also be an option
to add/remove encodings from the list at the top.

But since this list will not contain every possible character set
encoding (superset of ASCII) and we do not want to ask the user
initially about used encodings, we need a way to determine "typical"
ones, also based on the locale, but only the language/country pair.
One way would be to examine the output of "locale -a". In my opinion
this is suboptimal, because it only describes the current system.
E.g. on an Ubuntu system you will only see UTF-8 charsets, no ISO.

@Christian: What do you think about a translatable string listing
the typical encodings used in xy_WZ? Maybe you even have a better
idea :)

-- andi5