wrong names for access keys introduced by Bug 459413

RESOLVED FIXED

Status

defect
RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: adriank, Assigned: kairo)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(this is the SeaMonkey part of bug 462199)

The bug 459413 introduced this new entities in
notification.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 .
Hmm, right. I should have noticed that.

We might want to follow bug 462199 comment #1 here.
This patch changes us to use more L10n-sane .label/.accesskey.
Assignee: nobody → kairo
Status: NEW → ASSIGNED
Attachment #345375 - Flags: review?(neil)
Comment on attachment 345375 [details] [diff] [review]
change geolocation prompt to more L10n-sane .label/.accesskey

Do the other labels need to be fixed (the ones with no .label suffix, although the access keys still have .accesskey)?
Attachment #345375 - Flags: review?(neil) → review+
Not sure, the tools might know to associate "foo.accesskey" with "foo" as well, actually, even though it's clearer with .label.

We currently have 9 locales that already have those strings, I wonder if we can automatically fix them in some way.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.