Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 50507 invoked from network); 21 Nov 2003 11:24:17 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 21 Nov 2003 11:24:17 -0000 Received: (qmail 82790 invoked by uid 500); 21 Nov 2003 11:23:46 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 82764 invoked by uid 500); 21 Nov 2003 11:23:46 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 82743 invoked from network); 21 Nov 2003 11:23:45 -0000 Received: from unknown (HELO rapid.hartle-klug.de) (217.115.144.129) by daedalus.apache.org with SMTP; 21 Nov 2003 11:23:45 -0000 Received: from hartle-klug.com (pD9EA5A91.dip.t-dialin.net [217.234.90.145]) by rapid.hartle-klug.de (Postfix) with ESMTP id 7A5961B816 for ; Fri, 21 Nov 2003 11:29:36 +0100 (CET) Message-ID: <3FBDF4C4.1030002@hartle-klug.com> Date: Fri, 21 Nov 2003 12:19:32 +0100 From: Michael Hartle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [Woody] - status? References: <33373.10.0.0.5.1069397534.squirrel@ags01.agsoftware.dnsalias.com> <3FBDDF6C.1000208@outerthought.org> <3FBDE798.3040303@hartle-klug.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Hi Sylvain, > I don't agree here: vi is not i18nized and gives no visual feedback on > what its commands are. The purpose of access keys is to provide fast > access to fields that are _displayed_ in the page. And as the label of > these fields varies with the language, so should vary the access keys. > The fact that the access key must be present in the label text also > enforces this. hmm... the question is, does it always make sense to forcefully vary the access keys along with the field names when another language is used ? I agree, when using the concept of underlining the access key of fields, this requires the character to be present in the label, but perhaps other concepts might be more feasable in the long term, as this requirement might backlash in some cases; I cannot provide a good example right now, but what about localizations where many labels have very similar characters ? > And "habitualization" is related to what you usually need. Switch to > another language version of the office applications you usually use, > and you'll see that menu shortcuts will change also. An example that > comes to mind is MS Word, where "bold" is ctrl-B in english but ctrl-G > in french because the french for bold is "gras". As a consequence, explaining to someone how to make text bold in MS Word has to take into account the used localization of the application although the semantics of the task stay the same. The same applies when eg. you are working abroad, having to adapt to the new localization of commands for exactly the same tasks you previously used without having to think about explicitly. > Sylvain Best regards, Michael Hartle, Hartle & Klug Consulting GmbH