Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

L10n feedback wanted on bug 250141

0 views
Skip to first unread message

Joshua Cranmer

unread,
Sep 10, 2010, 10:33:09 AM9/10/10
to
(Note that this is limited to mailnews-related code)

For bug 250141, I decided to segregate the Cancel and Delete
functionality in the UI. One result of this is that the Cancel Message
(the name of the `Delete Message' menu item for newsgroups) is being
turned into a menu item under the `Message' menu. Note that the menu
item will be doing the exact same functionality (at least, as far as UI
is concerned); the only difference from a UI perspective is that it is
being moved to another menu.

Since there are different entries in the Message menu, this could
potentially impact the access keys used to access the menu item. When I
asked sipaq about this, this is what he recommended:

07:56< sipaq> jcranmer: Here's what I would do:
07:56< sipaq> Change the accesskey, but don't change the entity name
07:56< sipaq> CC thund...@localization.bugs on your bug and ask for localizer feedback there
07:57< sipaq> Post to mdl about it and ask for feedback and post there again when you commit your patch
07:57< sipaq> You can tell people that I told you to not change the accesskey entity name. Maybe I'm wrong ;)

So, if you have any feedback, please let me know.

Ricardo Palomares Martí­nez

unread,
Sep 10, 2010, 7:20:37 PM9/10/10
to
Joshua Cranmer escribió:


For me, the first and most important thing to ensure is that the label
entity name and the accesskey entity name match, so if the label
entity name is "cancelMessage.label", the accesskey entity name should
be "cancelMessage.accesskey", not "cancelMessage2.accesskey",
"cancelMessage.accesskey2" or something alike. Matching label and
accesskeys entity names allows tools to check troublesome values that
may lead to parenthesis (like in "Delete message (C)" supposing that
"C" was the accesskey value).

Provided the above is true, then there is two options from my POV:

1) Since I understand that the label string itself has not been
changed, then don't change anything and just warn here so localizers
check if the menu relocation leads to duplicate accesskeys in the
affected menu. This is my preferred choice.

2) Change BOTH label and accesskey entity names. This follows more
closely the rules for changes in L10n, but I think it will be more
annoying for both TB developers and most localizers.

However, I'm by no means an authoritive voice here, just a humble
localizer. :-)

HTH

0 new messages