« Return to Thread: new localization framework - comments
Re: new localization framework - comments
by Ray Kiddy-2
::
Rate this Message:
Ricardo Palomares Martinez wrote:
> Axel Hecht escribió:
>> Ricardo Palomares Martínez wrote:
>>> I may be wrong, but I see L20n as something potentially complex to
>>> handle files by hand, and if tools are expected to grow around it,
>>> some adjustments should be taken into account to make those tools more
>>> useful. I keep missing UI context information, which would enable
>>> tools to help with non-conflicting accesskey assignments, and I'd like
>>> to review comments oriented to warn localizers.
>> Accesskeys are hard. Mostly because in our applications, the context
>> isn't finite, damn extensions and overlays.
>
>
> Regarding extensions, I don't think anybody expects that a Mozilla
> product full-loaded with extensions doesn't have accesskey conflicts;
> even a lean, recently-installed one will have in some specific parts.
> The thing here is to minimize the cases as much as possible.
>
>
>> 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. Traditionally, access key collisions are too easy to just blame
on the last person to cause a conflict. This was certainly my experience
at Apple. The person most motivated to solve the problem is also under
the gun to just "get it fixed for right now".
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.
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.
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.
By the way, lots of good I10N and L18N checking and testing could go
through this manager as well.
thanx - ray
>> Marking this up in the l10n source has the down-side of actually
>> requiring that that is bugfree, too. Like, how would the UI coder know
>> which accesskey contexts are already in use, and find a unique one. That
>> sounds like pushing the problem somewhere where it might not be solved
>> as well.
>
>
> The problem exists indeed in en-US already. A developer adding a UI
> element with an accesskey surely knows where is he placing it, and
> should find easily the UI-context(s) applicable which, in turn, should
> ease the election of the accesskey. Of course it will involve more
> work for them, but if the UI-context can help to localizers by
> providing automated checks, those same checks will be available also
> for en-US.
>
>> Sorry for the lag.
>>
>
> Ditto. :-)
>_______________________________________________
dev-i18n mailing list
dev-i18n@...
https://lists.mozilla.org/listinfo/dev-i18n
> Axel Hecht escribió:
>> Ricardo Palomares Martínez wrote:
>>> I may be wrong, but I see L20n as something potentially complex to
>>> handle files by hand, and if tools are expected to grow around it,
>>> some adjustments should be taken into account to make those tools more
>>> useful. I keep missing UI context information, which would enable
>>> tools to help with non-conflicting accesskey assignments, and I'd like
>>> to review comments oriented to warn localizers.
>> Accesskeys are hard. Mostly because in our applications, the context
>> isn't finite, damn extensions and overlays.
>
>
> Regarding extensions, I don't think anybody expects that a Mozilla
> product full-loaded with extensions doesn't have accesskey conflicts;
> even a lean, recently-installed one will have in some specific parts.
> The thing here is to minimize the cases as much as possible.
>
>
>> 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. Traditionally, access key collisions are too easy to just blame
on the last person to cause a conflict. This was certainly my experience
at Apple. The person most motivated to solve the problem is also under
the gun to just "get it fixed for right now".
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.
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.
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.
By the way, lots of good I10N and L18N checking and testing could go
through this manager as well.
thanx - ray
>> Marking this up in the l10n source has the down-side of actually
>> requiring that that is bugfree, too. Like, how would the UI coder know
>> which accesskey contexts are already in use, and find a unique one. That
>> sounds like pushing the problem somewhere where it might not be solved
>> as well.
>
>
> The problem exists indeed in en-US already. A developer adding a UI
> element with an accesskey surely knows where is he placing it, and
> should find easily the UI-context(s) applicable which, in turn, should
> ease the election of the accesskey. Of course it will involve more
> work for them, but if the UI-context can help to localizers by
> providing automated checks, those same checks will be available also
> for en-US.
>
>> Sorry for the lag.
>>
>
> Ditto. :-)
>
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 |
