I'll vote that action names as they are exposed right now should not be
localized. If there is a desire to provide a localized form in the
future, new API should be introduced for the purposes of keeping
backwards compatibility.
Thanks!
Will
Steve Lee wrote:
> My response was more exposition
My response was more exposition.
Make it a no.
On 2/14/07, David Bolter <[EMAIL PROTECTED]> wrote:
> Thanks Bill.
>
> So we have a couple of votes for "no". I don't think Steve's was a
> strong "yes"? Especially if we add API down the road, for localized
> version of the name.
>
> Regarding addi
Thanks Bill.
So we have a couple of votes for "no". I don't think Steve's was a
strong "yes"? Especially if we add API down the road, for localized
version of the name.
Regarding adding a "getLocalizedActionName"... that sounds good except
might imply to the API reader that the current "get
At present the set of 'known action names' is pretty small.
As such, GOK can call the gettext() macro on the non-localized name, and
handle the localization of this small pool of names itself.
We intentionally left action names unlocalized to date, because of
reasons in your "case for 'no'" bel
Well you're adding the requirement that the action names are defined
to be end user friendly and not for developer consumption only. That
might not be a bad thing.
On 2/14/07, David Bolter <[EMAIL PROTECTED]> wrote:
> Fixed resend of message.
>
> Should the action names exposed by accessible widge
Fixed resend of message.
Should the action names exposed by accessible widgets/components be
localized?
The case for "yes":
AT like GOK can just expose the localized action names to the user as
GOK keys without having to worry about english user literacy.
The case for "no":
AT like Orca can do
Should the action names exposed by accessible widgets/components be
localized?
The case for "yes":
AT like GOK can just expose the action names to the user as GOK keys
without having to worry about english user literacy. GOK can build keys
from the action description instead.
The case for "no"