160346 - Most reply_header options are not localizeable

Status: RESOLVED DUPLICATE of bug 257378

(MailNews Core :: Internationalization, defect)

Description

[Robert Kaiser]

I had a report of a user who changed reply_header_type in a Mozilla German
build, and saw that it wasn't localized correctly.

He used this setting:

user_pref("mailnews.reply_header_type", 2);

0 = No reply header at all
1 = "<author> wrote:"
2 = "On <date> <author> wrote:"
3 = "<author> wrote On <date>:"

The "<author> wrote" string got localized correctly due to
http://lxr.mozilla.org/mozilla/source/mailnews/compose/resources/locale/en-US/composeMsgs.properties#256
256 mailnews.reply_header_authorwrote=%s wrote

The "On <date>" part, he noticed, didn't get localized correctly.

I believe that at least reply_header_ondate should be read from
composeMsgs.properties - perhaps we should even add reply_header_separator and
reply_header_colon to that one (not sure what other langauges need).

Comment 1

[marina]

adding Ray and Ying to the cc list

Comment 2

[nhottanscp]

>The "On <date>" part, he noticed, didn't get localized correctly.
Is this a same problem reported as bug 140882?

Comment 3

[marina]

it does look like the same problem to me. Naoki, my undretsanding is that the
fix for bug # 140882 is in works and wasn't checked into the branch yet..?

Comment 4

[nhottanscp]

The patch in bug 140882 needs reviews before check in to the trunk (no plan for
branch check in).

Comment 5

[marina]

i believe this is a dup of bug #140882, resolving as such

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

Comment 6

[Robert Kaiser]

bug 140882 is orthogonal to this one.

While bug 140882 deals with the local formats of the <date> field, this is about
the "On " part of reply_header_ondate.

What we'd need here is to have a line like this in composeMsgs.properties:
mailnews.reply_header_ondate=On %s
and appropriate handling of this string in the compose window.

Perhaps it would be nice to even have
mailnews.reply_header_separator=, 
mailnews.reply_header_colone=:
- not sure what different languages might need here...

Comment 7

[Robert Kaiser]

Reopening per Comment #6

Comment 8

[marina]

Robert, my undrestanding is that Naoki's fix that changes a default value of
"mailnews.reply_header_locale" from "en-US" to empty also deals with On ..(date)
string. Doesn't the comment # 8 on the bug # 140882 tell us that :" Am
18.07.2002 12:59, Ansgar Schrage schrieb:"?

Comment 9

[Robert Kaiser]

nope.

This commenbt talks about a *user set* reply_header_ondate, and I'm talking
about a *localized* reply_header_ondate.

Currently, if you set 
user_pref("mailnews.reply_header_type", 2);
(and no other reply_header prefs) with a German localized Mozilla build, you get
(in a reply to a mail from me)
"On 4/28/02 5:29 PM, Robert Kaiser schrieb:"

With the patch to bug 140882 applied, you get:
"On 28.04.2002 17:29, Robert Kaiser schrieb:"

What I want, is that it's
"Am 28.04.2002 17:29, Robert Kaiser schrieb:"
in that case.

See the difference?

You can get my desired result, if you aditionally set
user_pref("mailnews.reply_header_ondate", "Am %s");

but you shouldn't have to use that. A only half-way localized string surely
isn't the way to go here...

Comment 10

[Ludovic Hirlimann [:Usul]]

	
[e-mail]  , still willing to work on this ?

Comment 11

[Ludovic Hirlimann [:Usul]]

Makoto any body interested in finishing that that you know ?

Comment 12

[Simon Montagu :smontagu]

Is this bug still in effect? From code inspection it looks as if should be working correctly

The string is loaded as a localized pref at http://mxr.mozilla.org/comm-central/source/mailnews/compose/src/nsMsgCompose.cpp#134 and
http://mxr.mozilla.org/l10n/search?string=reply_header&find=&findi=&filter=^[^\0]*%24&hitlimit=&tree=l10n shows lots of localized versions including "Am %s" at http://mxr.mozilla.org/l10n/source/de/mail/chrome/messenger/messengercompose/composeMsgs.properties#326

CVS blame says it was fixed in bug 257378, so I'm going to close this as dupe. Please reopen if there is still a problem.