« Return to Thread: new localization framework - comments
Re: new localization framework - comments
by Ricardo Palomares Martínez
::
Rate this Message:
Ray Kiddy escribió:
> Ricardo Palomares Martinez wrote:
>> Axel Hecht escribió:
>> [Regarding accesskey conflicts]
>>> I'm not sure if there's a good way to solve this, let alone with
>>> non-Mozilla target applications in mind.
>>>
>
> I think there is a way to solve it. It requires a bit of investment,
> though. (..)
>
> There could be a component that keeps track of access key assignments.
> For example, an extension could apply an access key, but do it through
> the manager. The assignment would work only when the key was not assigned.
I'm not sure I'm getting you. Do you mean that the developer (or the
localizer, for that matter) won't be the one deciding the accesskey
while writing the code, but just let a component choose it at runtime
in a way that doesn't cause conflicts? Don't you think this will lead
to different accesskeys for each execution, or at least vary the
accesskey for a UI element depending of the installed extensions?
As a user, I'm pretty sure I wouldn't want the program to be
dinamically changing the accesskeys just because I've installed an
extension. Besides accessibility, accesskeys provide quick access to
options that aren't used so often to assign them a shortcut.
> Actually, an extension developer would want to supply an array of keys
> and the access key manager could assign the first one from the supplied
> list that is not taken. This will allow an extension developer to make
> use of access keys, as much as possible, without causing problems for
> others. And then there be hooks for fall-back logic and such. Etc, etc.
At first sight, I'd say that may actually involve more work. The
developer (I'm not restricting here to extension developers) would
pick their choice for every UI element, but after testing a nightly,
it could happen that the different keysets cooperate in a way that
makes some UI elements run out of "keys of choice", or make weird
assignments. The developer should re-think every keyset to get a
better assignment.
As I'm doing some changes to an old L10n tool, I also thought of
providing an automated accesskey assignment, but I discarded
inmediately because of reasons similar to the above explained.
> So, I can design and write an XPCOM component to do this. Getting it
> checked in would be another question. Getting anybody to use it would be
> another, much harder, question. Does anyone have a suggestion for how to
> proceed? Is there a good bug to use for this?
>
> I do not mind creating the component, but I also do not have time to
> spit into the wind.
I'd like to know Axel's opinion on this, as I may be a bit
short-sighed with these questions.
Ricardo
--
If it's true that we are here to help others,
then what exactly are the OTHERS here for?
_______________________________________________
dev-i18n mailing list
dev-i18n@...
https://lists.mozilla.org/listinfo/dev-i18n
> Ricardo Palomares Martinez wrote:
>> Axel Hecht escribió:
>> [Regarding accesskey conflicts]
>>> I'm not sure if there's a good way to solve this, let alone with
>>> non-Mozilla target applications in mind.
>>>
>
> I think there is a way to solve it. It requires a bit of investment,
> though. (..)
>
> There could be a component that keeps track of access key assignments.
> For example, an extension could apply an access key, but do it through
> the manager. The assignment would work only when the key was not assigned.
I'm not sure I'm getting you. Do you mean that the developer (or the
localizer, for that matter) won't be the one deciding the accesskey
while writing the code, but just let a component choose it at runtime
in a way that doesn't cause conflicts? Don't you think this will lead
to different accesskeys for each execution, or at least vary the
accesskey for a UI element depending of the installed extensions?
As a user, I'm pretty sure I wouldn't want the program to be
dinamically changing the accesskeys just because I've installed an
extension. Besides accessibility, accesskeys provide quick access to
options that aren't used so often to assign them a shortcut.
> Actually, an extension developer would want to supply an array of keys
> and the access key manager could assign the first one from the supplied
> list that is not taken. This will allow an extension developer to make
> use of access keys, as much as possible, without causing problems for
> others. And then there be hooks for fall-back logic and such. Etc, etc.
At first sight, I'd say that may actually involve more work. The
developer (I'm not restricting here to extension developers) would
pick their choice for every UI element, but after testing a nightly,
it could happen that the different keysets cooperate in a way that
makes some UI elements run out of "keys of choice", or make weird
assignments. The developer should re-think every keyset to get a
better assignment.
As I'm doing some changes to an old L10n tool, I also thought of
providing an automated accesskey assignment, but I discarded
inmediately because of reasons similar to the above explained.
> So, I can design and write an XPCOM component to do this. Getting it
> checked in would be another question. Getting anybody to use it would be
> another, much harder, question. Does anyone have a suggestion for how to
> proceed? Is there a good bug to use for this?
>
> I do not mind creating the component, but I also do not have time to
> spit into the wind.
I'd like to know Axel's opinion on this, as I may be a bit
short-sighed with these questions.
Ricardo
--
If it's true that we are here to help others,
then what exactly are the OTHERS here for?
_______________________________________________
dev-i18n mailing list
dev-i18n@...
https://lists.mozilla.org/listinfo/dev-i18n
« Return to Thread: new localization framework - comments
| Free embeddable forum powered by Nabble | Forum Help |
