You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Antonio Gallardo <ag...@agsoftware.dnsalias.com> on 2003/11/21 07:52:14 UTC
[Woody] - status?
Hi:
Reviewing old mails, I found we agreed to add to the woody template
specification an initial tag that was called <wd:hotkey>
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105848333001636&w=2
Please, follow the above thread.
I don't know if I miss something, but I don't see it anymore.
Best Regads,
Antonio Gallardo
Re: [Woody] - status?
Posted by Denis <de...@aic-info.com>.
> Do you meant <label for="name" accesskey="N">User <span
> class="accesskey">n</span>ame</label> ??
>
yes
> Since labels are produced by the XSL, this should be feasible, although
> not that straightforward since labels can contain not only text, but
> also arbitrary markup.
>
What about the following then:
<label for="name" User <acccess-key>n<acccess-key>ame</label>
Then convert it to proper HTML tag when applying xslt
Denis
Re: [Woody] - status?
Posted by Vadim Gritsenko <va...@verizon.net>.
Sylvain Wallez wrote:
> Denis wrote:
>
>> Hi Sylvain,
>>
>>
>>
>>> I also noticed that, although the HTML spec recommends to underline the
>>> accesskey in the label, no browser seems to do it. Any hint/advice on
>>>
>>
>> this?
>>
>> One way to get this is to create a <span> element around the
>> 'access-key'
>> and set its border-bottom style property to 1px solid.
>>
>>
>
> Do you meant <label for="name" accesskey="N">User <span
> class="accesskey">n</span>ame</label> ??
Will it break accessibility? I.e., will it mess up unusual browsers such
as screen readers, lynx, etc?
Vadim
Re: [Woody] - status?
Posted by Sylvain Wallez <sy...@apache.org>.
Denis wrote:
>Hi Sylvain,
>
>
>
>>I also noticed that, although the HTML spec recommends to underline the
>>accesskey in the label, no browser seems to do it. Any hint/advice on
>>
>>
>this?
>
>One way to get this is to create a <span> element around the 'access-key'
>and set its border-bottom style property to 1px solid.
>
>
Do you meant <label for="name" accesskey="N">User <span
class="accesskey">n</span>ame</label> ??
>OTOH, I just don't know how difficult it is to impement into woody ...
>
>
Since labels are produced by the XSL, this should be feasible, although
not that straightforward since labels can contain not only text, but
also arbitrary markup.
Sylvain
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [Woody] - status?
Posted by Denis <de...@aic-info.com>.
Hi Sylvain,
> I also noticed that, although the HTML spec recommends to underline the
> accesskey in the label, no browser seems to do it. Any hint/advice on
this?
One way to get this is to create a <span> element around the 'access-key'
and set its border-bottom style property to 1px solid.
OTOH, I just don't know how difficult it is to impement into woody ...
Regards,
Denis
Re: [Woody] - status?
Posted by Joerg Heinicke <jh...@virbus.de>.
Marc Portier wrote:
> please understand that if I'm suggesting wi:label en wi:acceskey (and
> same for Sylvain I persume) we are not suggesting to put this
> information in another place then the current definition file
>
> this is just pass-through information that is common for all instances,
> and therefore the suggestion could be to change from wd:label to
> wi:label in the definition file (and the i18n case with embedded
> wi:accesskey offers some argumentation if you ask me)
>
> it is the same as having a wi:styling and a wi:group elements inside the
> template-file
>
>
>
> hm, maybe the confusion comes from which value we attach to the action
> of XML-namespacing.
>
> in my head xml namespaces are mapping to devided semantic domains,
> saying something like 'this element has meaning inside this context'
>
> so what I am trying to say is that namespaces are not meant IMHO to map
> onto the created SoC (they often do, but doesn't seem to be a
> requirement AFAICS).
>
> As such I think that a distinct responsibility/role in the system could
> include making statements or reacting on statements that are built up of
> concepts from different semantic domains
>
> or in other words: if the form-designer-role is speaking about
> design-elements that are shared between all instances, then he probably
> should do that rather in the wi namespace?
>
>
> IMHO, allowing to mix namespaces in one XML file is the whole reasoning
> behind having them in the first place?
>
>
> just my 2c.
> (hoping it lowered confusion rather then adding to it)
> -marc=
No, Marc, I completely agree with you :-)
Joerg
--
System Development
VIRBUS AG
Fon +49(0)341-979-7419
Fax +49(0)341-979-7409
joerg.heinicke@virbus.de
www.virbus.de
Re: [Woody] - status?
Posted by Marc Portier <mp...@outerthought.org>.
Antonio Gallardo wrote:
> Marc Portier dijo:
>
>>well, I do think it does make sense to go for wi:label
>>
>>Thinking about it in some abstract terms, we could look at the wd-file
>>as some kind of a class definition, with all of its declared fields as
>>some kind of member-variable declarations
>
>
> The decision is hard to take. I thought the definition file is related to
> a form definition. Under this context it is correct to have an accesskey
> related to the label.
>
yes.
please understand that if I'm suggesting wi:label en wi:acceskey (and
same for Sylvain I persume) we are not suggesting to put this
information in another place then the current definition file
this is just pass-through information that is common for all instances,
and therefore the suggestion could be to change from wd:label to
wi:label in the definition file (and the i18n case with embedded
wi:accesskey offers some argumentation if you ask me)
it is the same as having a wi:styling and a wi:group elements inside the
template-file
hm, maybe the confusion comes from which value we attach to the action
of XML-namespacing.
in my head xml namespaces are mapping to devided semantic domains,
saying something like 'this element has meaning inside this context'
so what I am trying to say is that namespaces are not meant IMHO to map
onto the created SoC (they often do, but doesn't seem to be a
requirement AFAICS).
As such I think that a distinct responsibility/role in the system could
include making statements or reacting on statements that are built up of
concepts from different semantic domains
or in other words: if the form-designer-role is speaking about
design-elements that are shared between all instances, then he probably
should do that rather in the wi namespace?
IMHO, allowing to mix namespaces in one XML file is the whole reasoning
behind having them in the first place?
just my 2c.
(hoping it lowered confusion rather then adding to it)
-marc=
>
>>however, this 'label' and 'accesskey' stuff rather takes up the
>>equivalent role of 'static' variables that are shared across all
>>instances of the same class.
>
>
> Another thing is a general datatype repository (similiar like the one in
> XReports). I thought it is a good idea too, but it must be just as a
> helper to avoid is write the same datatypes over and over.
>
>
>>hm, just a way to look at it I guess?
>
>
> :-D
>
>>
>><snip topic="more agreement on wi:accesskey inside wi:label"/>
>
>
> I prefer wd:accesskey inside wd:label.
>
> Best Regards,
>
> Antonio Gallardo
>
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
Re: [Woody] - status?
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Marc Portier dijo:
> well, I do think it does make sense to go for wi:label
>
> Thinking about it in some abstract terms, we could look at the wd-file
> as some kind of a class definition, with all of its declared fields as
> some kind of member-variable declarations
The decision is hard to take. I thought the definition file is related to
a form definition. Under this context it is correct to have an accesskey
related to the label.
> however, this 'label' and 'accesskey' stuff rather takes up the
> equivalent role of 'static' variables that are shared across all
> instances of the same class.
Another thing is a general datatype repository (similiar like the one in
XReports). I thought it is a good idea too, but it must be just as a
helper to avoid is write the same datatypes over and over.
> hm, just a way to look at it I guess?
:-D
>
>
> <snip topic="more agreement on wi:accesskey inside wi:label"/>
I prefer wd:accesskey inside wd:label.
Best Regards,
Antonio Gallardo
Re: [Woody] - status?
Posted by Marc Portier <mp...@outerthought.org>.
Sylvain Wallez wrote:
> Marc Portier wrote:
>
>>
>>
>> Sylvain Wallez wrote:
>>
>>> Antonio Gallardo wrote:
>>>
>>>> Hi:
>>>>
>>>> Reviewing old mails, I found we agreed to add to the woody template
>>>> specification an initial tag that was called <wd:hotkey>
>>>>
>>>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105848333001636&w=2
>>>>
>>>> Please, follow the above thread.
>>>>
>>>> I don't know if I miss something, but I don't see it anymore.
>>>>
>>>>
>>>
>>> We currently only have <wd:hint> and <wd:help> implemented in the
>>> styling. Adding the hotkey is still to be done.
>>>
>>> Now what about naming it <wd:accesskey> or <wd:access-key>? This
>>> would be more similar to the corresponding "acceskey" HTML attribute.
>>>
>>> I also noticed that, although the HTML spec recommends to underline
>>> the accesskey in the label, no browser seems to do it. Any
>>> hint/advice on this?
>>
>>
>>
>> first idea is to have:
>>
>> <wd:label><wd:accesskey>N</wd:accesskey>ame:</wd:label>
>>
>> of course we will need some fit with the i18n support
>>
>> suggestion, just keep the current:
>> <wd:label>
>> <i18n:text key="prompt.name" />
>> </wd:label>
>>
>> where
>> <message key="prompt.name"><wi:accesskey>N</wi:accesskey>ame:</message>
>
>
>
> I love this, as it avoids separate definitions of label and key in the
> i18n catalogue.
>
yep
>> ? hm, I don't actually don't know if current i18n transformer is
>> supporting mixed content-model messages, anyone?
>
>
>
> Yes, it does (IIRC, this is new in 2.1).
>
cool, we might consider the introduction of an example on this somewhere
(couldn't easily find anything on website or wiki)
>> also this approach would require us however to make some upfront
>> suggestions on the order of template and i18n transformer? (and thus
>> reflect that in the namespace-prefix in the message)
>
> As i18n must come after the woodytransformer, <wi:accesskey> makes
> sense. But when the label is in the definition, we'll have a
> <wi:accesskey> inside a <wd:label>...
>
> I suggested some time ago to have <wi:label> in the form definition
> since, its just "transported" by the widget to produce the instance (no
> processing occurs on it), but I'm not sure that mixing prefixes is so
> intuitive. OTOH, "wi:" clearly indicates that it's an optional and
> view-only data.
>
well, I do think it does make sense to go for wi:label
Thinking about it in some abstract terms, we could look at the wd-file
as some kind of a class definition, with all of its declared fields as
some kind of member-variable declarations
however, this 'label' and 'accesskey' stuff rather takes up the
equivalent role of 'static' variables that are shared across all
instances of the same class.
hm, just a way to look at it I guess?
<snip topic="more agreement on wi:accesskey inside wi:label"/>
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
Re: [Woody] - status?
Posted by Sylvain Wallez <sy...@apache.org>.
Marc Portier wrote:
>
>
> Sylvain Wallez wrote:
>
>> Antonio Gallardo wrote:
>>
>>> Hi:
>>>
>>> Reviewing old mails, I found we agreed to add to the woody template
>>> specification an initial tag that was called <wd:hotkey>
>>>
>>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105848333001636&w=2
>>>
>>> Please, follow the above thread.
>>>
>>> I don't know if I miss something, but I don't see it anymore.
>>>
>>>
>>
>> We currently only have <wd:hint> and <wd:help> implemented in the
>> styling. Adding the hotkey is still to be done.
>>
>> Now what about naming it <wd:accesskey> or <wd:access-key>? This
>> would be more similar to the corresponding "acceskey" HTML attribute.
>>
>> I also noticed that, although the HTML spec recommends to underline
>> the accesskey in the label, no browser seems to do it. Any
>> hint/advice on this?
>
>
> first idea is to have:
>
> <wd:label><wd:accesskey>N</wd:accesskey>ame:</wd:label>
>
> of course we will need some fit with the i18n support
>
> suggestion, just keep the current:
> <wd:label>
> <i18n:text key="prompt.name" />
> </wd:label>
>
> where
> <message key="prompt.name"><wi:accesskey>N</wi:accesskey>ame:</message>
I love this, as it avoids separate definitions of label and key in the
i18n catalogue.
> ? hm, I don't actually don't know if current i18n transformer is
> supporting mixed content-model messages, anyone?
Yes, it does (IIRC, this is new in 2.1).
> also this approach would require us however to make some upfront
> suggestions on the order of template and i18n transformer? (and thus
> reflect that in the namespace-prefix in the message)
As i18n must come after the woodytransformer, <wi:accesskey> makes
sense. But when the label is in the definition, we'll have a
<wi:accesskey> inside a <wd:label>...
I suggested some time ago to have <wi:label> in the form definition
since, its just "transported" by the widget to produce the instance (no
processing occurs on it), but I'm not sure that mixing prefixes is so
intuitive. OTOH, "wi:" clearly indicates that it's an optional and
view-only data.
> biggest plus for this approach to me seems to be that you are assuring
> that the access-key _is_ part of the label, regardless of the language?
Yep. And formatting becomes trivial, since there's no need to look the
the key and split the label.
> in any case I would find it logical to have the accesskey-node
> dependent (i.e. child or attribute) of the label attribute
>
>
>
> thinking of other possibilities I'm only arriving at a specific
> attribute to wd:label
>
> <wd:label acceskey="i18n:accesskey.name" >
> <i18n:text>prompt.name</i18n:text>
> <wd:label>
>
> where then
> prompt.name=Name:
> accesskey.name=N
>
> seems easier at first, but still fails to support the underlining?
Well, it makes a verbose and complex definition, and doesn't help to
write the XSL...
> what do you guys think?
+1 for <wi:accesskey> in labels!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [Woody] - status?
Posted by Michael Hartle <mh...@hartle-klug.com>.
Marc Portier wrote:
> I agree, but IMHO you are talking about two different things here...
<snip type="explaination"/>
Touché, I haven't seen it this way - thanks for pointing out ;-)
> taking up your point however, next to the accesskey, we might think
> about a @shortcut which then needs to be catched by some js-key-event
> handler
>
> however, I would think of those as being children/attributes of the
> form rather then of any of the widgets (let alone their labels)
>
> making sense ?
From my point of view, this sounds good.
> -marc=
Best regards,
Michael Hartle,
Hartle & Klug Consulting GmbH
[OT]: language chavinism (was: [Woody] - status?)
Posted by Joerg Heinicke <jh...@virbus.de>.
Sylvain Wallez wrote:
>>> 2/ command-shortcuts: key-strokes that replace the need for diving
>>> through a menu and function as some kind of macro-triggers
>>>
>>> see, if I use MS Word in the dutch version then saving a file through
>>> the access-keys of the menu become ALT-B-B (bestand -> bewaren) while
>>> the nglish version has ALT-F-S (files -> save)
>>>
>>> in both versions the shortcut CTRL-S does the same.
>>> (just like the CTRL-X,C,V are never 'localized')
>>
>>
>> In spanish version you can also use Ctrl+G (Guardar), that is diferent
>> from Ctrl+S.
>>
>
> Well, you see Marc, chauvinism is not a french only virtue/fault (choose
> your preferred).
>
> ;-D
>
> Sylvain
I personally like the idea of language chauvinism as you called it. I read
the French are really strict with the usage of English words: they translate
everything, even Personal Computer. Might be extreme, but I like it much
more than the so called "Denglisch" (Deutsch + Englisch = German + English)
word mix in German linguistic usage.
Articles (in German):
http://www.sueddeutsche.de/jobkarriere/erfolggeld/artikel/236/8228/
http://www.sueddeutsche.de/jobkarriere/erfolggeld/artikel/247/16231/
http://vds-ev.de/denglisch/sprachpanscher/sprachhunzer.php
The worst are the "Denglisch" words not known in English, when German
marketers wants to sound more English than the English men themself. The
most extreme sample: Handy. I guess not many people without knowledge of the
German language can imagine what it should mean. It's the Denglisch word for
Mobile Phone though we also know the word Mobiltelefon.
So enough ranted. Preserve your chauvinism ;-)
Joerg
--
System Development
VIRBUS AG
Fon +49(0)341-979-7419
Fax +49(0)341-979-7409
joerg.heinicke@virbus.de
www.virbus.de
Re: [Woody] - status?
Posted by Sylvain Wallez <sy...@apache.org>.
Antonio Gallardo wrote:
>Marc Portier dijo:
>
>
>>2/ command-shortcuts: key-strokes that replace the need for diving through a menu and function as some kind of macro-triggers
>>
>>see, if I use MS Word in the dutch version then saving a file through the access-keys of the menu become ALT-B-B (bestand -> bewaren) while the nglish version has ALT-F-S (files -> save)
>>
>>in both versions the shortcut CTRL-S does the same.
>>(just like the CTRL-X,C,V are never 'localized')
>>
>>
>
>In spanish version you can also use Ctrl+G (Guardar), that is diferent from Ctrl+S.
>
>
Well, you see Marc, chauvinism is not a french only virtue/fault (choose
your preferred).
;-D
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [Woody] - status?
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Marc Portier dijo:
> 2/ command-shortcuts: key-strokes that replace the need for diving
> through a menu and function as some kind of macro-triggers
>
> see, if I use MS Word in the dutch version then saving a file through
> the access-keys of the menu become ALT-B-B (bestand -> bewaren) while
> the nglish version has ALT-F-S (files -> save)
>
> in both versions the shortcut CTRL-S does the same.
> (just like the CTRL-X,C,V are never 'localized')
In spanish version you can also use Ctrl+G (Guardar), that is diferent
from Ctrl+S.
Best Regards,
Antonio Gallardo
Re: [Woody] - status?
Posted by Marc Portier <mp...@outerthought.org>.
Michael Hartle wrote:
> Marc Portier wrote:
>
>> <message key="prompt.name"><wi:accesskey>N</wi:accesskey>ame:</message>
>>
>> ? hm, I don't actually don't know if current i18n transformer is
>> supporting mixed content-model messages, anyone?
>>
>> also this approach would require us however to make some upfront
>> suggestions on the order of template and i18n transformer? (and thus
>> reflect that in the namespace-prefix in the message)
>>
>> biggest plus for this approach to me seems to be that you are assuring
>> that the access-key _is_ part of the label, regardless of the language?
>
>
> Just a wild thought, this might lead to web applications that have
> different hotkeys for the same task (or behave differently for the same
> hotkey used) depending on the language they are i18n-ed to ? Just
> imagine how difficult using the "vi" would become (in terms of
> documentation, explaining, accidential changes of i18n configuration for
> a user, etc) if all shortcuts (command "dd" => "delete a line") would
> turn out to be different in other languages, eg. German (command "lösche
> eine Zeile" => "lz" ??).
>
I agree, but IMHO you are talking about two different things here...
1/ accesskey: visual clues with underscores that indicate fast-access on
screens you are (maybe) seeing for the first time
2/ command-shortcuts: key-strokes that replace the need for diving
through a menu and function as some kind of macro-triggers
see, if I use MS Word in the dutch version then saving a file through
the access-keys of the menu become ALT-B-B (bestand -> bewaren) while
the nglish version has ALT-F-S (files -> save)
in both versions the shortcut CTRL-S does the same.
(just like the CTRL-X,C,V are never 'localized')
(since vi was born well before menus emerged, I would consider all of
those as of the second type)
> This would be counter-intuitive and work against "habitualization", the
> natural process of turning "compound" tasks requiring thought (which
> buttons do I have to press now for removing a line) into routine tasks
> without requiring thought - somewhat similar to what its like to learn
> driving a car. Jef Raskin has written the very interesting book "The
> Humane Interface" (ISBN: 0-201-37937-6) on this topic, well worth reading.
>
taking up your point however, next to the accesskey, we might think
about a @shortcut which then needs to be catched by some js-key-event
handler
however, I would think of those as being children/attributes of the form
rather then of any of the widgets (let alone their labels)
making sense?
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
Re: [Woody] - status?
Posted by Sylvain Wallez <sy...@apache.org>.
Marc Portier wrote:
> Sylvain Wallez wrote:
>
>> 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".
>
>
> LOL, really Sylvain: this only shows french chauvinism (or the lack of
> any belgian similar feeling)
Grmmph... ;-)
> fact is: we do have ctrl-B in belgian language versions (but maybe
> this is only because the V for 'vetjes' was already taken?)
Note that we do have also the usual Z-X-C-V shortcuts for
undo-cut-copy-paste. This is, I guess, because the definition of these
keys is related to a geographical placement on the keyboard rather than
a letter from the corresponding word (although key layout also differs
among languages).
But looking at it closer, I see that although menu shortcuts not always
corresponds to the actual word defining the action, access keys always
do, since they have to be displayed as underlined.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [Woody] - status?
Posted by Marc Portier <mp...@outerthought.org>.
Sylvain Wallez wrote:
>
> 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".
>
LOL, really Sylvain: this only shows french chauvinism
(or the lack of any belgian similar feeling)
fact is: we do have ctrl-B in belgian language versions
(but maybe this is only because the V for 'vetjes' was already taken?)
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
Re: [Woody] - status?
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Michael Hartle dijo:
> 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 ?
I think the best is to let Cocoon users decide about this. Is they want
universal or localized (l10n) accesskey.
If the above is true, then we need to support the l10n and user that does
not want l10n, simply avoid this feature.
Best Regards,
Antonio Gallardo
Re: [Woody] - status?
Posted by Michael Hartle <mh...@hartle-klug.com>.
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
Re: [Woody] - status?
Posted by Sylvain Wallez <sy...@apache.org>.
Michael Hartle wrote:
<snip/>
> Just a wild thought, this might lead to web applications that have
> different hotkeys for the same task (or behave differently for the
> same hotkey used) depending on the language they are i18n-ed to ? Just
> imagine how difficult using the "vi" would become (in terms of
> documentation, explaining, accidential changes of i18n configuration
> for a user, etc) if all shortcuts (command "dd" => "delete a line")
> would turn out to be different in other languages, eg. German (command
> "lösche eine Zeile" => "lz" ??).
>
> This would be counter-intuitive and work against "habitualization",
> the natural process of turning "compound" tasks requiring thought
> (which buttons do I have to press now for removing a line) into
> routine tasks without requiring thought - somewhat similar to what its
> like to learn driving a car. Jef Raskin has written the very
> interesting book "The Humane Interface" (ISBN: 0-201-37937-6) on this
> topic, well worth reading.
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.
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".
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [Woody] - status?
Posted by Michael Hartle <mh...@hartle-klug.com>.
Marc Portier wrote:
> <message key="prompt.name"><wi:accesskey>N</wi:accesskey>ame:</message>
>
> ? hm, I don't actually don't know if current i18n transformer is
> supporting mixed content-model messages, anyone?
>
> also this approach would require us however to make some upfront
> suggestions on the order of template and i18n transformer? (and thus
> reflect that in the namespace-prefix in the message)
>
> biggest plus for this approach to me seems to be that you are assuring
> that the access-key _is_ part of the label, regardless of the language?
Just a wild thought, this might lead to web applications that have
different hotkeys for the same task (or behave differently for the same
hotkey used) depending on the language they are i18n-ed to ? Just
imagine how difficult using the "vi" would become (in terms of
documentation, explaining, accidential changes of i18n configuration for
a user, etc) if all shortcuts (command "dd" => "delete a line") would
turn out to be different in other languages, eg. German (command "lösche
eine Zeile" => "lz" ??).
This would be counter-intuitive and work against "habitualization", the
natural process of turning "compound" tasks requiring thought (which
buttons do I have to press now for removing a line) into routine tasks
without requiring thought - somewhat similar to what its like to learn
driving a car. Jef Raskin has written the very interesting book "The
Humane Interface" (ISBN: 0-201-37937-6) on this topic, well worth reading.
Best regards,
Michael Hartle,
Hartle & Klug Consulting GmbH
Re: [Woody] - status?
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On 21 Nov 2003, at 09:48, Marc Portier wrote:
> where
> <message key="prompt.name"><wi:accesskey>N</wi:accesskey>ame:</message>
>
> ? hm, I don't actually don't know if current i18n transformer is
> supporting mixed content-model messages, anyone?
>
I find this works :
<message key="prompt.name"><p>blah</p><p>blah</p></message>
but not this:
<message key="prompt.name"><p>blah <a href="blag">blah</a></p></message>
HTH
regards Jeremy
Re: [Woody] - status?
Posted by Marc Portier <mp...@outerthought.org>.
Sylvain Wallez wrote:
> Antonio Gallardo wrote:
>
>> Hi:
>>
>> Reviewing old mails, I found we agreed to add to the woody template
>> specification an initial tag that was called <wd:hotkey>
>>
>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105848333001636&w=2
>>
>> Please, follow the above thread.
>>
>> I don't know if I miss something, but I don't see it anymore.
>>
>>
>
> We currently only have <wd:hint> and <wd:help> implemented in the
> styling. Adding the hotkey is still to be done.
>
> Now what about naming it <wd:accesskey> or <wd:access-key>? This would
> be more similar to the corresponding "acceskey" HTML attribute.
>
> I also noticed that, although the HTML spec recommends to underline the
> accesskey in the label, no browser seems to do it. Any hint/advice on this?
first idea is to have:
<wd:label><wd:accesskey>N</wd:accesskey>ame:</wd:label>
of course we will need some fit with the i18n support
suggestion, just keep the current:
<wd:label>
<i18n:text key="prompt.name" />
</wd:label>
where
<message key="prompt.name"><wi:accesskey>N</wi:accesskey>ame:</message>
? hm, I don't actually don't know if current i18n transformer is
supporting mixed content-model messages, anyone?
also this approach would require us however to make some upfront
suggestions on the order of template and i18n transformer? (and thus
reflect that in the namespace-prefix in the message)
biggest plus for this approach to me seems to be that you are assuring
that the access-key _is_ part of the label, regardless of the language?
in any case I would find it logical to have the accesskey-node dependent
(i.e. child or attribute) of the label attribute
thinking of other possibilities I'm only arriving at a specific
attribute to wd:label
<wd:label acceskey="i18n:accesskey.name" >
<i18n:text>prompt.name</i18n:text>
<wd:label>
where then
prompt.name=Name:
accesskey.name=N
seems easier at first, but still fails to support the underlining?
what do you guys think?
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
Re: [Woody] - status?
Posted by mr...@collegenet.com.
news <ne...@sea.gmane.org> wrote on 11/21/2003 01:02:28 AM:
> I also noticed that, although the HTML spec recommends to underline the
> accesskey in the label, no browser seems to do it. Any hint/advice on
this?
>
> Sylvain
This CSS is very nice:
label:after {content:"(" attr(accesskey) ") "}
where accesskey attribute is set in <label>, automatically displays the
accesskey attribute after the <label> element (you need to i18n the
accesskey attribute)
The after pseudo-element also works for widget elements, e.g.
input:after {content:"(" attr(accesskey) ") "}
where accesskey attribute is set in <input> widget
Additional clever ways to use attr(accesskey) are described in:
http://devedge.netscape.com/viewsource/2003/reveal-accesskey/
This works only for Mozilla, Netscape6+, Konqueror, and Safari. No MSIE;
although I haven't checked MSIE 6.x. (Personally, I don't care.)
--Michael (who is having trouble keeping up with Woody posts, much less
the pace of development)
Re: [Woody] - status?
Posted by Sylvain Wallez <sy...@apache.org>.
Antonio Gallardo wrote:
>Hi:
>
>Reviewing old mails, I found we agreed to add to the woody template
>specification an initial tag that was called <wd:hotkey>
>
>http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105848333001636&w=2
>
>Please, follow the above thread.
>
>I don't know if I miss something, but I don't see it anymore.
>
>
We currently only have <wd:hint> and <wd:help> implemented in the
styling. Adding the hotkey is still to be done.
Now what about naming it <wd:accesskey> or <wd:access-key>? This would
be more similar to the corresponding "acceskey" HTML attribute.
I also noticed that, although the HTML spec recommends to underline the
accesskey in the label, no browser seems to do it. Any hint/advice on this?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com