329431 - EdDialogOverlay.xul cleanup for localizers

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[Dwayne Bailey]

This patch cleans up some of the bad reuse and .accesskey associations that confuse localisers.

Comment 1

[Dwayne Bailey]

Attachment: Fixes entity naming for localisers

Comment 2

[Phil Ringnalda (:philor)]

Over to Editor, since those are shared strings.

Comment 3

[Phil Ringnalda (:philor)]

Grr, and back to you.

Comment 4

[Dwayne Bailey]

Comment on attachment 214104 [details] [diff] [review]
Fixes entity naming for localisers

As phil says these are shared strings with the editor so asking the owner of the editor component for review.

Comment 5

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Comment on attachment 214104 [details] [diff] [review]
Fixes entity naming for localisers

r=[e-mail]

Comment 6

[[e-mail]]

Comment on attachment 214104 [details] [diff] [review]
Fixes entity naming for localisers

Perhaps an L10N note that the two labels should probably have the same text but different access keys?

Comment 7

[Dwayne Bailey]

(In reply to comment #6)
> Perhaps an L10N note that the two labels should probably have the same text but
> different access keys?

I don't think that will be needed since the English already indicates a choice of other accesskey.  If the translator chooses conflicting ones these can be corrected as they do elsewhere.

Comment 8

[Dwayne Bailey]

Thanks for all the review, etc.  I don't have commit rights and am also not sure what the next steps are.  Is someone able to commit this patch for me?

Comment 9

[Reed Loden [:reed]]

Checking in editor/ui/dialogs/content/EdDialogOverlay.xul;
/cvsroot/mozilla/editor/ui/dialogs/content/EdDialogOverlay.xul,v  <--  EdDialogOverlay.xul
new revision: 1.45; previous revision: 1.44
done
Checking in editor/ui/locales/en-US/chrome/dialogs/EdDialogOverlay.dtd;
/cvsroot/mozilla/editor/ui/locales/en-US/chrome/dialogs/EdDialogOverlay.dtd,v  <--  EdDialogOverlay.dtd
new revision: 1.3; previous revision: 1.2
done

Comment 10

[Rimas Kudelis [use needinfo to ping]]

shouldn't "Choose File" end with U+2026 instead of three fullstop characters?

Comment 11

[Dwayne Bailey]

(In reply to comment #10)
> shouldn't "Choose File" end with U+2026 instead of three fullstop characters?

Judging from other changes I've seen in l10n related files it does seem that ... is being replaced by U+2026.  I would suggest creating a new bug for that and blocking bug 329432