409980 - Probably "Mail" literal instead of a variable to be replaced by branding in "Mail currently sending.... wait?" dialog

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

[RickieES aka Ricardo Palomares]

In this string:

http://lxr.mozilla.org/mozilla1.8/source/mail/locales/en-US/chrome/messenger/messengercompose/composeMsgs.properties#302

the literal "Mail" is used instead of a variable which, on branding, gets replaced to "Thunderbird".

I've got a bug related to es-ES localization (bug 409949) and I'm not sure if the use of "Mail" as a literal word was made on purpose on en-US. Shouldn't it use something similar to:

http://lxr.mozilla.org/mozilla1.8/source/mail/locales/en-US/chrome/messenger/messenger.properties#113

Comment 1

[Magnus Melin [:mkmelin]]

Attachment: proposed fix

Use brandShortname instead of "Mail", and add accesskeys for the buttons.

Comment 2

[Karsten Düsterloh]

Comment on attachment 294771 [details] [diff] [review]
proposed fix

>Index: mail/locales/en-US/chrome/messenger/messengercompose/composeMsgs.properties
>===================================================================
>-quitComposeWindowMessage=Mail is currently in the process of sending a message.\nWould you like to wait until the message has been sent before quitting or quit now?
>-quitComposeWindowQuitButtonLabel=Quit
>-quitComposeWindowWaitButtonLabel=Wait
>+quitComposeWindowMessage2=%1$S is currently in the process of sending a message.\nWould you like to wait until the message has been sent before quitting or quit now?
>+quitComposeWindowQuitButtonLabel2=&Quit
>+quitComposeWindowWaitButtonLabel2=&Wait

I don't think that it is necessary to rename the properties, since there aren't any real semantic changes. As long as KaiRo doesn't think they're required, please change the text only.

r=me with that.
(I verified that the & does work on Linux and is hidden on Mac. I don't have Windows.)

Comment 3

[Magnus Melin [:mkmelin]]

Semantic change may be a bit relative... Without renaming the properties there is no guarantee localizers will pick up on the changes. Isn't the point to always rename them if its something localizers should change too? As opposed to typos etc. 

Comment 4

[RickieES aka Ricardo Palomares]

(In reply to comment #2)
> 
> I don't think that it is necessary to rename the properties, since there
> aren't any real semantic changes. As long as KaiRo doesn't think they're
> required, please change the text only.
> 


As a localizer, I honestly think the key names should change or otherwise those of us trusting in tinderboxes status won't catch the fix.

Comment 5

[Robert Kaiser]

Comment on attachment 294771 [details] [diff] [review]
proposed fix

quitComposeWindowMessage definitely needs the key name change, and I think it's probably better to do it for the other two as well, so r=me for the original patch.
Karsten, the problem is that most localizers won't notice that there was an change they need to adopt unless we change the key names and make their tinderbox turn orange.

Comment 6

[Karsten Düsterloh]

Well, honestly, this sucks.
If you need to change the property name each time you change its value, one of the main advantages of using them in the first place (separation of code and language) is lost. Localizers should watch out for changes in the base language (which happens to be en-US, but this isn't the point) after their last translation date.
But this isn't the right place to discuss this.

Comment 7

[RickieES aka Ricardo Palomares]

(In reply to comment #6)
> Well, honestly, this sucks.
> If you need to change the property name each time you change its value, one of
> the main advantages of using them in the first place (separation of code and
> language) is lost. Localizers should watch out for changes in the base language
> (which happens to be en-US, but this isn't the point) after their last
> translation date.


Note that some L10n tools (MozillaTranslator, for instance), don't actually require that, since they keep an internal repository and thus will catch up the changes, no matter if the entity/key name change or not.

However, nor tinderboxes nor compare-locales.pl can do it and won't be able to detect if a changed entity in en-US have been updated in ab-CD.

As a related issue, I've been unable to run cvs diff against my local en-US locale vs. the one in Trunk and get actual diff results (it works on branches, though). The only likely solution I can think of would be a Bonsai query, but I'm not sure we can get one showing just changes in L10n files.

Comment 8

[Karsten Düsterloh]

I've posted to mozilla.dev.l10n <[e-mail]> about the issue, let's discuss it there and file (and fix) relevant bugs then.

Comment 9

[Magnus Melin [:mkmelin]]

So I guess we're in agreement this is the way we have to do it for now.

Comment 10

[Magnus Melin [:mkmelin]]

David: sr ping

Comment 11

[David :Bienvenu]

Comment on attachment 294771 [details] [diff] [review]
proposed fix

thx for the patch

Comment 12

[Magnus Melin [:mkmelin]]

Thanks for the review!

Checking in mail/components/compose/content/MsgComposeCommands.js;
/cvsroot/mozilla/mail/components/compose/content/MsgComposeCommands.js,v  <--  MsgComposeCommands.js
new revision: 1.126; previous revision: 1.125
done
Checking in mail/components/compose/content/messengercompose.xul;
/cvsroot/mozilla/mail/components/compose/content/messengercompose.xul,v  <--  messengercompose.xul
new revision: 1.114; previous revision: 1.113
done
Checking in mail/locales/en-US/chrome/messenger/messengercompose/composeMsgs.properties;
/cvsroot/mozilla/mail/locales/en-US/chrome/messenger/messengercompose/composeMsgs.properties,v  <--  composeMsgs.properties
new revision: 1.16; previous revision: 1.15
done
Checking in mailnews/compose/resources/content/MsgComposeCommands.js;
/cvsroot/mozilla/mailnews/compose/resources/content/MsgComposeCommands.js,v  <--  MsgComposeCommands.js
new revision: 1.412; previous revision: 1.411
done
Checking in mailnews/compose/resources/content/messengercompose.xul;
/cvsroot/mozilla/mailnews/compose/resources/content/messengercompose.xul,v  <--  messengercompose.xul
new revision: 1.298; previous revision: 1.297
done
Checking in suite/locales/en-US/chrome/mailnews/compose/composeMsgs.properties;
/cvsroot/mozilla/suite/locales/en-US/chrome/mailnews/compose/composeMsgs.properties,v  <--  composeMsgs.properties
new revision: 1.89; previous revision: 1.88
done

->FIXED