KSelectAction

[Nicolas Goutte]

On Sunday 30 July 2006 17:21, Stephan Kulow wrote:
> Am Sonntag, 30. Juli 2006 12:29 schrieb Ingo Klöcker:
> > And wrt to translation one should probably make more use of the "i18n
> > with context" function. If we could standardize on usage of the
> > context, e.g. "Menu View -> Use Fixed Font", and then make the
> > translation tools so smart that they group all "Menu View" items
> > together then the translator should be able to find good accels (with
> > the help of a manager proposing accels of course). Alternatively, the
> > translators could simply omit setting accels and leave it to the
> > manager. I don't see why we shouldn't hardcode good accels for the
> > English "translation" just because of other translations.
>
> Oh, I'm all for using good accels. So whenever you see a situation where
> you think the manager can't do a better job than the programmer, just
> hardcode one. Then the translator will hardcode less too and give the
> manager more room.
>
> But the (german translation of the) Edit menu of the kmail composer I just
> have open is a good example that you will never be able to find a perfect
> match - managed or not. So let's hardcode the cases that are likely to be
> used more often by users and give the rest to the manager (which could be
> changed to warn again on conflicting hard codes by default for the moment).

Sorry but I am still unsure how this is supposed to work, especially with 
non-Latin translations. 

Here the translators has anyway to give a Latin character as accelerator. So 
any "manager" should not try to be smarter. (Also the risk is  that the 
hardcoded way of being "smarter" could mismatch with the target 
audience/users of the translation.)

>
> Greetings, Stephan

Have a nice day!