Re: new localization framework - comments

Ray Kiddy wrote:
> 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.
> =


Trying to get my head into this one again.

I'm not sure that doing an array of accesskeys is going to be as stable =

as we would like it to be. Like, this would end up depending on the =

order in which overlays are loaded, right? Which might be a hash =

thingie, thus you could change the order by just adding a new item, and =

even though no conflict to be removed changed, the resolution could change.

Sounds like a bag of bees to me. Anyway, sounds to me like something =

that should be discussed in a group with a wider audience, maybe m.d.t.xul?

Axel