462199 - wrong names for access keys introduced by Bug 444642

Status: NEW

(Firefox :: General, defect)

Description

[Adrian Kalla [:adriank]]

The patch 336599 from bug 444642 introduced this new entities in browser.properties:

+geolocation.exactLocation=Exact Location (within 10 feet)
+geolocation.exactLocationKey=E
+geolocation.neighborhoodLocation=Neighborhood (within 1 mile)
+geolocation.neighborhoodLocationKey=N
+geolocation.nothingLocation=Nothing
+geolocation.nothingLocationKey=o

Unfortunately, our l10n tools like compare-locales or the translate toolkit do not recognize entities of the form *Key as access keys, so this names needs to be changed to e.g. *AccessKey .

Comment 1

[Axel Hecht [:Pike]]

Actually, I'd prefer .label and .accesskey for both.

Adrian, can we create a rewrite script for l10n for this?

Comment 2

[Adrian Kalla [:adriank]]

short update: it looks like compare-locales 0.5/0.6 doesn't distinguish between access and command keys (re.compile('[kK]ey')), so it does detect it properly.
The compare-locales version I'm working on does this differently and because of that it doesn't work.

But there is still the problem, that a localizer will not know if this is an access or a command key. And we are not using a simple "Key" anywhere else.

Comment 3

[Adrian Kalla [:adriank]]

Pike: gandalf was working on that script - cc-ing gandalf...

Comment 4

[Mark Finkle (:mfinkle) (use needinfo?)]

so we'll end up with something like this?:

geolocation.exactLocation.label=Exact Location (within 10 feet)
geolocation.exactLocation.accesskey=E

Comment 5

[Robert Kaiser]

Exactly, see attachment 345375 [details] [diff] [review] on bug 462200, where I did this for SeaMonkey.

Comment 6

[Zibi Braniecki [:zbraniecki][:gandalf]]

adrian: if you need any help with the script, let me know

Comment 7

[Rick Riewer]

Attachment: same problem

Thanks from mascconsmifer1978.