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

VERIFIED FIXED in mozilla0.9.6


MailNews Core
18 years ago
4 years ago


(Reporter: Håkan Waara, Assigned: nhottanscp)



Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(1 attachment)



18 years ago
Currently these two strings:

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

are hardcoded in nsMsgCompose::CreateMessage() and

They should both be put in a .properties file so they can be localizable.
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

18 years ago
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

18 years ago
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

18 years ago
 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

18 years ago
Kat, could you answer the question from hwaara@chello.se? Thanks.

Comment 6

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

Comment 7

18 years ago
We should remove the strings to a properties file.

Reassigned to ducarroz.
Assignee: rchen → ducarroz

Comment 8

18 years ago
> 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.
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

18 years ago
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

18 years ago
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

18 years ago
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

18 years ago
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

18 years ago
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.


17 years ago
Depends on: 75377


17 years ago
Keywords: l12y

Comment 15

17 years ago
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

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

Comment 17

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

Comment 18

17 years ago
Comment from bug #89569:

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

see bug 75377 and 

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

No english is better than english in localized build. 

Comment 19

17 years ago
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> :'.


17 years ago
Hardware: PC → All


17 years ago
Keywords: intl, nsBranch


17 years ago
Keywords: intl

Comment 20

17 years ago
I hope you don't mind I take this bug.

Assignee: ducarroz → ftang

Comment 21

17 years ago
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

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

Comment 23

17 years ago
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.


17 years ago
Whiteboard: nsbranch+
Target Milestone: --- → mozilla0.9.4

Comment 24

17 years ago
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 <john@doe.com> 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

17 years ago
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

17 years ago
too late for m9.4. move to m9.5
Whiteboard: nsbranch+
Target Milestone: mozilla0.9.4 → mozilla0.9.5


17 years ago
Priority: -- → P2

Comment 27

17 years ago
nsbranch- since Frank moved it to 0.9.5
Keywords: nsbranch → nsbranch-

Comment 28

17 years ago
move to m96
Target Milestone: mozilla0.9.5 → mozilla0.9.6

Comment 29

17 years ago
give nhotta to drive this issue and design
Assignee: ftang → nhotta

Comment 30

17 years ago
cc to ducarroz
Target Milestone: mozilla0.9.6 → mozilla0.9.7

Comment 31

17 years ago
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

17 years ago
Created attachment 55310 [details] [diff] [review]
Moved the hard coded reply header strings to pref so they can be editable.

Comment 33

17 years ago
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.


17 years ago
Blocks: 107067


17 years ago
Keywords: nsbranch-

Comment 34

17 years ago
*** Bug 31947 has been marked as a duplicate of this bug. ***
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
Attachment #55310 - Flags: review+

Comment 36

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

Comment 37

17 years ago
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.
+      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

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

Filed bug 107884 for UI.

Comment 40

17 years ago
mark as fixed
Last Resolved: 17 years ago
Resolution: --- → FIXED


17 years ago
Target Milestone: mozilla0.9.7 → mozilla0.9.6

Comment 41

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

Comment 42

17 years ago
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

16 years ago
Verified as fixed with a Ja build.
Product: MailNews → Core
Product: Core → MailNews Core


7 years ago
Blocks: 621264
Blocks: 1070049
You need to log in before you can comment on or make changes to this bug.