[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: KSelectAction
From: Hans Meine <hans_meine () gmx ! net>
Date: 2006-07-31 11:37:39
Message-ID: 200607311337.43623.hans_meine () gmx ! net
[Download RAW message or body]
On Sunday 30 July 2006 10:58, Stephan Kulow wrote:
> Am Freitag, 28. Juli 2006 15:00 schrieb Hans Meine:
> > Maybe that's overly complex (it
> > would have to be translated, too...) and the existing manager already
> > contains some basic AI logic (I did not check).
>
> The manager already has weightening - your message has some suprises
> to me though. You combined "Check for New Mail" with "cnema" - why do you
> think that &e is better than &f as in &for?
Ingo already gave a good description. I just feel that "Check" and "New" are
the important words here and both are next-best represented with "e" after
their initial letters.
I find hard-coding accels a poor solution though. If it's done action-wise (I
suppose so), then having a clash in *one* menu forces you to choose a worse
accel for all other places where the action is plugged.
Furthermore, I fear that translators will translate strings with accelerators
to ones with, and strings without to strings without. Actually, both the
original authors (or usability people) and the translators would have to
carefully look at the menus, searching for clashes or bad accelerators. That
would have to be done on a regular basis, periodically, nobody forces you,
and you actually have to *use* the program with all its menus a lot. I don't
think that works.
As an outcome, I think we agree that:
1) Hardcoded accels (the ampers&and way) are bad, because they can easily lead
to clashes and the same holds for every translation.
2) Theroretically, there is room for improvement - the current manager cannot
automatically find the best accelerator, which requires some kind of
intelligence.
3) Solving 2) is made much more difficult by the need for i18n.
AFAICS, 2) could only be solved with either human or artifical intelligence.
Simple AI methods could be to add some rules to the manager to prefer
capitalized words, include language-specific black-lists ("for" etc.) or
maybe prefer e.g. vowels. Human intelligence could mean that programmers can
include a set of preferable accelerators with action strings, which must be
very easy and translateable. IMHO every approach not including accels in the
gettext string would be overkill, e.g. "[cnema]Check for New Mail" or
similar. (No, I do not think that it looks nice. ;-/ )
Greetings,
Hans
[Attachment #3 (application/pgp-signature)]
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic