75377 - Add a bool pref to control localizable reply-header

Status: RESOLVED DUPLICATE of bug 70842

(MailNews Core :: Localization, defect)

Description

[Håkan Waara]

spinoff from bug 23615...

Right now (or when the above mentioned bug is fixed) we always reply with
english reply header. The reason for this is because if we had these strings
non-hardcoded (localizable) and recipent of an email didn't understand the same,
native language as the sender then it would be confusing for the recipent.

The proposed solution for this (per sspitzer, timeless and nhotta) is that we
should use 4 invisible prefs/flags:

1. "<author> wrote:" - english
2. "<author> wrote:" - localizable
3. "On <date>, <author> wrote:" - english
4. "On <date>, <author> wrote:" - localizable

and then if the recipent is using the same chartype/character encoding as the
sender then send the localizable version (which of them to send is dependant
upon which pref is set in the UI) and if not, then fall back on the english,
hard-coded version.

There's a bug about localizing the reply header; to not hardcode "wrote:" and
the like. That should probably be blocked by this bug since we need to write the
code to *determine* if we can use the localized reply-header before we can use it.

Comment 1

[Håkan Waara]

as noted, this bug blocks bug 70842.

Comment 2

[nhottanscp]

>if the recipent is using the same chartype/character encoding
>as the sender then send the localizable
This is not possible since the reply may go to multiple recipients. It should
change to "if the original message has the same charset of the sender's
localized value of the default charset for message send then ...".

The other way is to provide UI to the user, an option to use localized strings
or ASCII strings. Or make those strings editable through UI.

We need to decide the spec first, cc to msanz.

Comment 3

[Katsuhiko Momoi]

Some users may be also writing English-only msgs under
a Japanese encoding. So the encoding does not necessarily
match the content language sometimes. I think providing an
option might be the only viable way of doing this.

Comment 4

[nhottanscp]

>So the encoding does not necessarily match the content language sometimes.
This is true. I would be annoyed if I always get the localized string for my
default charset and no way to correct it other than editing the string manually
every time.

But the simple on/off option allows the localized strings to be used for any
charsets and may end up with sending strings which might not be readable (e.g.
question marks, NCR).

So, we may still want to do the charset matching. Or we need to explain clearly
in the UI about the meaning of turning on that option.

Comment 5

[rchen]

reassigned to nhotta.

Comment 6

[nhottanscp]

Change title and reassign to [e-mail].
I think adding a new backend pref is the only thing needed for bug 70842.
Please do that with bug 70842.

Comment 7

[Håkan Waara]

Actually, this is not my concern - the point was raised by others in the bug so
I went ahead and filed a bug.

I don't want this bug.

Comment 8

[Håkan Waara]

nhotta, I may have misread/misunderstood, but what kind of boolpref do you want?

Is all you want a boolpref to determine whether to use the
localized-version/english version of the reply-header?

Should this pref be visible in some way?  Please elaborate and I will consider
fixing this...

Comment 9

[nhottanscp]

I think this should be a part of bug 70842 because you cannot just put localized
strings unconditionally.
Reassign to ducarroz, I mean to assign to the same owner of bug 70842 (instead I
reassigned to the reporter).

Comment 10

[Tobias Burnus]

I don't see how you can use the character encoding: I write emails always in 
ISO-8857-1 regardless if I write German, English, Italian or Frensh (for the 
latter -15 is better to get oe).
The character encoding is IMHO usefull for some asiatic languages (though using 
Unicode this doesn't help either).
It also depends on style: I write a lot of English emails so a default to 
English would be best for me whereas my parents would use the l10n version.

Comment 11

[Håkan Waara]

I want someone to make a decision here. I really want to send my emails with a
localized date-header!

Comment 12

[Håkan Waara]

nominating

Comment 13

[scottputterman]

marking nsbeta1- and moving to future.

Comment 14

[Frank Tang]

>The reason for this is because if we had these strings
>non-hardcoded (localizable) and recipent of an email didn't understand 
>the same, native language as the sender then it would be confusing for the 
recipent.

Not a valid argument, 
1. if you remove hardcoded and put into string bundle, the localizer have the 
choice to decide keep it in English or not, without remove the hard coded 
string, the l10n process have no choice.
2. localization can choose to translate "%s wrote:" to "%s:" which do not have 
English, neither some language user won't understand.
3. even we translate "%s wrote:" to native language, most of the user the sender 
communicate will be in the same language, so the reader will understand. 
However, if you don't translate it and keep it in English as wrote, most of the 
reader won't understand the English word "wrote".
I think the easiest way is to change it from "%s wrote:" to "%s:"

Comment 15

[Frank Tang]

"because if we had these strings
non-hardcoded (localizable) and recipent of an email didn't understand the same,
native language as the sender then it would be confusing for the recipent."

this is a very veryt strange argument because in the current situration:
"if we keep it in English, then receipent of an email didn't understand English
then it would be confusing for the recipent"

How many percent of chance that a languag A user will send mail to a person who
do not understand language A? -  Percentage B
How many percent of chance that a language A user will send mail to a person who
do not understand English? - Percentage C

Will B > C or C > B for all the internet users? 

As I understand, localized version (At least Chinese) always reply Subject,
Sender, Date in localized string.

Comment 16

[Tobias Burnus]

Not neccessarily a bool, but some kind of preference would be nice. (Also for
the address book besides the html/plain text preference, a language preference.)

For me it is for instance rather common to write in English (~50%) and in German
(45%) and in other languages (~5%). Whereas my aunt writes frequently in German
(60%) but also in French (30%) and in Italian (~10%).

So a bool wouldn't be sufficient, but some way to select the language would be
very much needed.

Comment 17

[Frank Tang]

grab this bug to ftang

Comment 18

[Frank Tang]

moz0.9.5

Comment 19

[msanz]

nsbranch- since Frank moved it to 0.9.5

Comment 20

[Takayuki Tei]

add myself to cc list.

Why don't we take advantage of X-Accept-Language header?
I know not many MUA uses it, but at least Netscape/Mozilla do.

Comment 21

[Bertilo Wennergren]

I can't beleive it is even being considered to decide for people
with hard-coded text strings which language they should use
in their messages. And I can't beleive character encodings
are confused with languages.

Let the users themselves decide how their reply headers should
look with suitable placeholder for <author> etc.

Hard coding English text that can't be changed is very, very
rude, and very, very non-i18n.

Comment 22

[Frank Tang]

move to m0.9.6

Comment 23

[Frank Tang]

give to nhotta to drive the design and issue

Comment 24

[nhottanscp]

Backend change was done by bug 70842, now the strings are in pref and editable.
Front end issue to be addressed by the UI bug 107884.

*** This bug has been marked as a duplicate of 70842 ***