Re: new localization framework - comments

Ricardo Palomares Martinez wrote:
> Axel Hecht escribi=F3:
>> Ricardo Palomares Mart=ED=ADnez 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. :-)
> =