Thunderbird Options Dialog String Changes

[Scott MacGregor]

Just a heads up that we landed a lot of string changes to the Thunderbird Options dialog yesterday. In particular, it might be good to double check the access keys for the various panels in the Options / Preferences dialog for your locale.

For more details, see Bug #361434 for more details.

Cheers,

-Scott

[Ricardo Palomares Martinez]

Scott MacGregor escribió:

Please, don't break entity naming conventions:

===================================================================
RCS file:
/cvsroot/mozilla/mail/locales/en-US/chrome/messenger/preferences/general.dtd,v
retrieving revision 1.5.2.4
retrieving revision 1.5.2.2
diff -u -r1.5.2.4 -r1.5.2.2
---
mozilla/mail/locales/en-US/chrome/messenger/preferences/general.dtd 28
Nov 2006 21:15:32 -0000 1.5.2.4
+++
mozilla/mail/locales/en-US/chrome/messenger/preferences/general.dtd 9
Nov 2006 22:27:29 -0000 1.5.2.2
@@ -10,11 +10,15 @@
<!ENTITY checkNow.label "Check Now">
<!ENTITY checkNow.accesskey "N">
(...)
<!ENTITY location.label "Location:">
-<!ENTITY location1.accesskey "o">
+<!ENTITY location.accesskey "L">

It's already hard enough to follow accesskey changes in Thunderbird
with its monster messenger.dtd file (please, can we do something about
it?) without having to deal with different name prefixes for label and
accesskey pairs.

As current l10n rules enforces changing entity names when anything
more than a typo happens, if an accesskey must be modified, like this
case, I propose adding a rule that says that "accesskey" and
"accesskey2" are valid suffixes for accesskeys. I think it will be
easier for L10n tools to check accesskeys correctness based on two
different suffixes than on two different prefixes (actually, MT can do
this now).

OTOH, if it is the label itself the one changing, then the right move
would IMHO be to rename both the label and the associated accesskey
(maybe the accesskey letter still will be valid for en-US, but not for
other locales).

Ricardo.

--
If it's true that we are here to help others,
then what exactly are the OTHERS here for?

[Axel Hecht]

Hrm, I forgot about the tools being picky here.

I actually think that accesskeys that got changed due to new conflicts
from the rest of the page (without the corresponding label changing)
shouldn't really need to be changed. The accesskeys need to be checked
in the live app afterwards, anyway.

Axel

[Ricardo Palomares Martinez]

Axel Hecht escribió:

> Ricardo Palomares Martinez wrote:
>> As current l10n rules enforces changing entity names when anything
>> more than a typo happens, if an accesskey must be modified, like this
>> case, I propose adding a rule that says that "accesskey" and
>> "accesskey2" are valid suffixes for accesskeys. I think it will be
>> easier for L10n tools to check accesskeys correctness based on two
>> different suffixes than on two different prefixes (actually, MT can do
>> this now).
>>
>> OTOH, if it is the label itself the one changing, then the right move
>> would IMHO be to rename both the label and the associated accesskey
>> (maybe the accesskey letter still will be valid for en-US, but not for
>> other locales).
>
> Hrm, I forgot about the tools being picky here.
>

Actually, not picky, it's just that they are not so smart. :-)

> I actually think that accesskeys that got changed due to new conflicts
> from the rest of the page (without the corresponding label changing)
> shouldn't really need to be changed. The accesskeys need to be checked
> in the live app afterwards, anyway.

FWIW, MozillaTranslator doesn't really need the key changing strategy,
since it has the old string value stored and uses it to detect
changes. I understand that compare-locales.pl needs it, though.

BTW, I've just filed this:

https://bugzilla.mozilla.org/show_bug.cgi?id=362385

due to a typo in latest changes to Thunderbird en-US files.