70842 - " wrote:" and "--- Original Message ---" should be localizable

Status: VERIFIED FIXED

(MailNews Core :: Localization, defect, P2)

Description

[Håkan Waara]

Currently these two strings:

* " wrote:"
* "--- Original Message ---"

are hardcoded in nsMsgCompose::CreateMessage() and
QuotingOutputStreamListener::QuotingOutputStreamListener.

They should both be put in a .properties file so they can be localizable.

Comment 1

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

I completely agree with reporter. All MUAs distributed on the french marked
use "%s a écrit:" instead of "%s wrote:" for instance... Are these two the
only 2 localizable strings ?

Comment 2

[ji]

The strings are in the the mime.properties file. But for some reason they are
not used. Ray, could you confirm?
We decided not to translate the string in Japanese N6 (Please see bugscape bug
1797). Some mail clients also don't translate this, like Outlook Express.

Comment 3

[Håkan Waara]

Honestly though, do we want to be like Outlook Express? I think not.

And I can't access Bugscape (because I'm no Netscape employee), so can you
please conclude why we can't translate this to Japanese?

Comment 4

[rchen]

 Ji, are you sure bug 1797 related to this bug? It looks like a javascript bug. 
I know there are some stings in mime.properties can't be translated due to the 
core bugs. I need to double check wither this is the case.

Comment 5

[ji]

Kat, could you answer the question from [e-mail]? Thanks.

Comment 6

[Håkan Waara]

More questions: why are the strings appended and hardcoded in C++? Why is the
strings still there?

Comment 7

[rchen]

We should remove the strings to a properties file.

Reassigned to ducarroz.

Comment 8

[Katsuhiko Momoi]

> And I can't access Bugscape (because I'm no Netscape employee), 
> so can you please conclude why we can't translate this to 
> Japanese?

It's not a matter of "cannot translate" but rather one of
which would be better, to translate or not translate.

In the case of Japanese, we decided during Communicator days
that translating this string would mean that if you send
a message in languages otehr than Japanese, you would 
be sending unreadable string in Japanese. On the other
hand, ASCII string, "you wrote:", would be readable in messages
of any language. 

This is the main reason why we chose not to translate
the string.  
I think it's up to each localizer to decide whether or not
this should be translated.

Now if there is a way to use the translated string only when
the message is in Japanese, we might do so. In fact, this might
be a good thing to do. I don't think the current code distinguishes
what string to use based on the language of messages.

Comment 9

[Jean-Francois Ducarroz]

That could be done I think easely by looking at the charset of the original
message. Do we want to support more than english (or any iso-latin "language")
and japanese?

Comment 10

[Katsuhiko Momoi]

J-F, it's not that easy for Western languages like French
or German because all that the charset says is "ISO-8859-1".
For Japanese, this might be easy but as a general code to handle
any language message we support, I am not so sure. So, the question
is what should be the spec for such a language switch and can
we make a reasonable spec that covers not just a single language
case but all of them.

Comment 11

[scottputterman]

I vote for leaving this untranslated for the moment if making it work correctly
is going to be as complicated as it sounds.  It sounds like 67504 is a dup of this.

Comment 12

[Katsuhiko Momoi]

Please note that I did not say that these strings should
remain hard-coded. In fact I believe they should be
translatable. The only suggestion I made is that 
if so, then in some languages like Japanese,
we should not translate it. 

The other thing I would request is that when you extract
these strings, don't break up a sentence:

If you're going to extract "%s wrote: ", this whole
thing should be one definition. Localizers then
can choose not leave only "%s: " withoout translating
"wrote". There are other ways in which localizers can
translate or not translate this item.

Comment 13

[Håkan Waara]

It's OK for me to not translate to Japanese, but it should NOT be hardcoded
either way. Let's move it to a .properties file and then argue about how to
translate the best way.

Comment 14

[msanz]

I agree with making it localizable (if it's not already), but I wouldn't request
the fix to detect each language in the next release. It'd be nice to have, but
we can wait and there are other more critical bugs. My 2 cents.

Comment 15

[Ben Bucksch (:BenB)]

IMO, if you touch this code, you should make the string entirely
user-defineable. The user could then insert printf[-like] placeholders for
"original author", "date" and whatever else we want to provide. I don't think,
this is hard to code.

Comment 16

[Ola Thoresen]

*** Bug 86404 has been marked as a duplicate of this bug. ***

Comment 17

[Karl Ove Hufthammer]

*** Bug 89569 has been marked as a duplicate of this bug. ***

Comment 18

[Karl Ove Hufthammer]

Comment from bug #89569:

------- Additional Comments From Frank Tang 2001-07-06 17:55 -------

see bug 75377 and 
http://lxr.mozilla.org/seamonkey/source/mailnews/compose/src/nsMsgCompose.cpp#14
60

I think we should not hard code that string. And in the localized build maybe 
we 
should use
"%s :"
instead of
"%s worte:" or any translation of "wrote"

No english is better than english in localized build. 

Comment 19

[Karl Ove Hufthammer]

Even if 'Name <e-mail>:' is used, this needs to be localizable. For example, in 
French, there should be a space before the colon: 'Name <e-mail> :'.

Comment 20

[Frank Tang]

I hope you don't mind I take this bug.

Comment 21

[Frank Tang]

we can fix this bug in the following way, even break into several stages:

Stage 1:
1. get the sending charset
2. convert the charset to langgroup1
3. get the current locale
4. convert the locale to langgrup2
5. if langgrup1 == langgrup2, use the localized string bundle
6. otherwise, use English (see Step 2 for improvement)

for example, if we are on a German build and try to send ISO-8859-1 email
1. ISO-8859-1 
2. ISO-8859-1 -> x-western
3. de
4. de -> x-western
5. x-western == x-western = > use German from the string bundle


for example, if we are on a German build and try to send ISO-2022-JP email
1. ISO-2022-JP
2. ISO-2022-JP -> ja
3. de
4. de -> x-western
5. ja != x-western 
6. use "wrote %s"

Step 2:  (replace 6 above)
7. Find the prefer language list from the preference
8. iterate through the language in the list
9. convert langupage to a langgrup3
10. if langgrup3 == langgrup1, get a translation from a locale-insensitive 
property file using the language as the key
11. if we have the translation of that langauge, use it
12. otherwise repeate step 8-10
13. after we run out of the list 

Comment 22

[Ben Bucksch (:BenB)]

Is "x-western" not overly broad? What, if I (de) am talking with a french guy?

Comment 23

[Håkan Waara]

ftang, this bug depends on bug 75377 (as does many other bugs). If you plan to
fix this, please look into fixing that first.  Thanks.

Comment 24

[Ola Thoresen]

But please.
This should NOT be automagically localized.
I do not want it to be in Spanish, just because I happen to sit on a computer in Spain.
What I wnt is to be able to change it to whatever text i want, including a few "wildcards" like the realname, mailaddress, date and so on.
So MY string can look like "John Doe <[e-mail]> wrote: " 
While someone else might want it to be something like "So sprecht John Doe: ".
Wouldn't this be just as easy, as trying to figure out how to say "John Doe wrote:" in 100 languages?

Comment 25

[Håkan Waara]

The strings are ONLY allowed to something other than english if that language
pack is chosen.

Even if I am on a Swedish system, the text should be in English unless I have
the Swedish langpack.

Comment 26

[Frank Tang]

too late for m9.4. move to m9.5

Comment 27

[msanz]

nsbranch- since Frank moved it to 0.9.5

Comment 28

[Frank Tang]

move to m96

Comment 29

[Frank Tang]

give nhotta to drive this issue and design

Comment 30

[nhottanscp]

cc to ducarroz

Comment 31

[nhottanscp]

Looks like we want to keep the English strings even if we provide localized string.
So, make the strings localizable but keep English as default then provide UI to
allow switching to the localized string (also allow editing the string).

* English string can be remained hard coded or moved to .properties but tagging
a note not to translate.
* Add localizable strings to .properties.
* Add pref items which may contain localized strings or user edited strings.

Comment 32

[nhottanscp]

Attachment: Moved the hard coded reply header strings to pref so they can be editable.

Comment 33

[nhottanscp]

I moved the reply header strings to pref so they can be editable.
So UI may provide ways to set the strings (e.g. get strings from .property, 
provide editable widgets).
Also added a locale string as a pref, this is used for date formatting.
In future, we might be able to use locale to select strings from 
possible multiple locale packages.
The pref string uses "%s wrote" so the order of the words can be changed.
Also there is an option (by the type) to change the order of date string and 
author string.
The patch has backend change only, it does not have changes for .property file 
and UI. Probably, we need a separate bug for UI.

Comment 34

[nhottanscp]

*** Bug 31947 has been marked as a duplicate of this bug. ***

Comment 35

[Jean-Francois Ducarroz]

Comment on attachment 55310 [details] [diff] [review]
Moved the hard coded reply header strings to pref so they can be editable.

looks good. R=ducarroz

Comment 36

[Håkan Waara]

Nhotta, Are you confident this change won't slow down the time it takes to open
a compose window?

Comment 37

[nhottanscp]

It used to read one pref value "mailnews.reply_header_type". After the chage, it
will read 7 pref values. I don't think that is significant. It is possible to
read the header type and decide what other pref to load.

Comment 38

[(not reading, please use [e-mail] instead)]

+      nsAutoString citePrefixDate;
+      nsAutoString citePrefixAuthor;
+      citePrefixDate.Truncate(0);
+      citePrefixAuthor.Truncate(0);


why do you need to do truncate the strings?

other than that, it looks fine.  sr=sspitzer

Comment 39

[nhottanscp]

Checked in, removed two lines.
+      citePrefixDate.Truncate(0);
+      citePrefixAuthor.Truncate(0);

Filed bug 107884 for UI.

Comment 40

[nhottanscp]

mark as fixed

Comment 41

[nhottanscp]

*** Bug 75377 has been marked as a duplicate of this bug. ***

Comment 42

[ji]

Filed bug 120870 for a backend implementation that makes reply read the string
from .property file in case the user doesn't specify it in pref, so localization
engineers can have a choice to localize those strings in localized builds.

Comment 43

[ji]

Verified as fixed with a Ja build.