In bug 525238 the semantic meaning for several strings in the following files was changed, without changing the entity names: - mail/locales/en-US/chrome/messenger/imapMsgs.properties - 5102 - 5109 - mail/locales/en-US/chrome/messenger/localMsgs.properties - 4030 - mail/locales/en-US/chrome/messenger/messengercompose/composeMsgs.properties - 12579 - 12580 - 12581 We thereby ensure that many/most of our localizers will not notice the changes and that therefore improvements will not make it to approx. 50% of our userbase. This also applies to SeaMonkey. Please change this ASAP, so that this can still make the string freeze for TB 3.1b2/TB 3.1.

yup, will do

The problem is bigger, unfortunately. http://mxr.mozilla.org/l10n-mozilla1.9.2/search?string=4032&find=localMsgs.properties&findi=&filter= I can't even use those numbers which are *free* in en-US, because they have been removed, because the locales don't even *remove* strings. That means all the strings I added in the middle of the file will go wrong. I have to change them all to go at the end (*and* pay attention that nothing was removed from the end). That sucks massively. Please fix the i10n tools! If en-US changes, they need to be re-translated, no matter the ID.

FWIW, independently, filed bug 555212 about the numeric IDs. That doesn't solve the fundamental problem in the l10n tools, though.

Taking bug. I'm changing the IDs of all the ID-based strings I added.

WFM

Comment on attachment 435203 [details] [diff] [review] Fix, v1 Thanks for doing this. Changes look good, just one minor comment: >diff --git a/mail/locales/en-US/chrome/messenger/messengercompose/composeMsgs.properties b/mail/locales/en-US/chrome/messenger/messengercompose/composeMsgs.properties >+## @name NS_ERROR_SMTP_AUTH_FAILURE >+12597=Unable to authenticate to SMTP server %S. Please check the password, and verify the 'Authentication method' in 'Account Settings | Outgoing server (SMTP)'. >+ >+## @name NS_ERROR_SMTP_AUTH_GSSAPI >+12598=The Kerberos/GSSAPI ticket was not accepted by the SMTP server %S. Please check that you are logged in to the Kerberos/GSSAPI realm. >+ >+## @name NS_ERROR_SMTP_AUTH_MECH_NOT_SUPPORTED >+12599=The SMTP server %S does not support the selected authentication method. Please change the 'Authentication method' in the 'Account Settings | Outgoing Server (SMTP)'. >+ >+## @name NS_ERROR_SMTP_AUTH_NOT_SUPPORTED >+12600=Unable to authenticate to SMTP server %S. It does not support authentication (SMTP-AUTH) but you have chosen to use authentication. Please change the 'Authentication method' to 'None' in the 'Account Settings | Outgoing Server (SMTP)' or contact your email service provider for instructions. I know the rest of the file doesn't have them, but could you add a localization note to these strings for the %S please. At some stage we should do the rest of the file, but we can do that if we change numbers -> strings (or at some other appropraite time). sr=Standard8 with those added.

OK, will do before checkin.

Added localization note. Commited as <http://hg.mozilla.org/comm-central/rev/0ebd348108ed> FIXED

:sipaq: what about the agreement to stop using numeric entity names?

Rimas, that is covered by bug 555212. The fix here is a short-term solution.

(In reply to comment #9) > :sipaq: what about the agreement to stop using numeric entity names? Rimas: In any case, I think that's something we should try and get to after 3.1 is released/branched, given the shorter timescale to 3.1 and reducing the load on l10n for 3.1 (especially as the current set of changed strings for 3.1 is quite small).

That's cool. I'm just surprised we're still introducing NEW numeric ID's. We could have at least avoided this, I think...

> We could have at least avoided this, I think... No. I checked, and IIRC the code used getStringFromID(int id). Thus, bug 555212.