111267 - Some characters are displayed as unicode codepints in offline messages

Status: RESOLVED FIXED

(MailNews Core :: Internationalization, defect)

Description

[ji]

This is moved from bugscape. (http://bugscape/show_bug.cgi?id=10794)

With a Ja build, after going offline, when selecting a message which is not
downloaded, the message view page will display an explanation saying that the
message is not downloaded and you need to go back to online.... In this message,
some characters are displayed as raw unicode codepoints. 

Steps to reproduce:
1. Launch Mail.
2. Select File | Offline, a dialog will pop up asking if you want to download
the message, answer no.
3. Select a message in the mail box, the explanation will be displayed in
message view pane.

Comment 1

[ji]

Nominating for nsbeta1, this looks very bad on Ja builds.

Comment 2

[ji]

Attachment: A screenshot on Ja build.

Comment 3

[ji]

Copied Ray's comments on bugscape bug:
------ Additional Comments From [e-mail] 2001-11-13 14:53 -------

The problem is the string contains several "\n\" at the end of the lines to
continue the message. The parser can't take care of "\\uxxxx", which causes the
problem.  I wonder the second "\" is necessary for properties file. 

Comment 4

[nhottanscp]

I think this is a localization issue. "\\uxxxx" is treated as '\' and "uxxxx"
whcih is a correct behavior.

Comment 5

[rchen]

Can you give us the advice to localize the string without the problem?

nocachedbodybody =The body of this message has not been downloaded from \n\
the server for reading offline. To read this message, \n\
you must reconnect to the network, choose Offline from \n\
the File menu and then select Work Online.\n\
In the future, you can select which messages or folders to read offline. To do 
\n\
this, choose Offline from the file menu and then select Synchronize. You can \n\
adjust the Disk Space preference to prevent the downloading of large messages.

Comment 6

[nhottanscp]

Tao, do you have suggestion? Can that be \n instead of \n\?

Comment 7

[rchen]

Apparently \n is not working. The work around I can think of is to remove all 
\n\ to make it a single huge line and it works. But it sucks.

Comment 8

[rchen]

Parser should do a better job. It should not connect the second \ character to 
the first character in the next line. Naoki, Do you know who owns the parser? We 
should talk to them regarding this issue. 

Reopen the bug. 

Comment 9

[nhottanscp]

I think Harish owns parser, cc to him. But this has to be resolved at string
bundle level before getting to the parser.

Comment 10

[rchen]

Do you know who owns the string bundle handling?

Comment 11

[nhottanscp]

Reassign to tao.

Comment 12

[nhottanscp]

nsbeta1-
 L10N can workaround by combining into a single line

Comment 13

[tao]

per #12

Comment 14

[Ying-Lin Xia]

This bug should be closed now, since we had a fix in bug 144345.

Comment 15

[Christopher Hoess (gone)]

FIXED per comment.