555164 - Semantic meaning for account manager strings was changed, without changing the entity names

Status: RESOLVED FIXED

(Thunderbird :: Account Manager, defect)

Description

[Simon Paquet [:sipaq]]

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.

Comment 1

[Ben Bucksch (:BenB)]

yup, will do

Comment 2

[Ben Bucksch (:BenB)]

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.

Comment 3

[Ben Bucksch (:BenB)]

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

Comment 4

[Ben Bucksch (:BenB)]

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

Comment 5

[Ben Bucksch (:BenB)]

Attachment: Fix, v1

WFM

Comment 6

[Mark Banner (:standard8)]

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.

Comment 7

[Ben Bucksch (:BenB)]

OK, will do before checkin.

Comment 8

[Ben Bucksch (:BenB)]

Added localization note.

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

FIXED

Comment 9

[Rimas Kudelis [use needinfo to ping]]

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

Comment 10

[Simon Paquet [:sipaq]]

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

Comment 11

[Mark Banner (:standard8)]

(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).

Comment 12

[Rimas Kudelis [use needinfo to ping]]

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

Comment 13

[Ben Bucksch (:BenB)]

> We could have at least avoided this, I think...

No. I checked, and IIRC the code used getStringFromID(int id). Thus, bug 555212.