Re: new localization framework - comments

> 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.
>