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.
Nominating for nsbeta1, this looks very bad on Ja builds.
Keywords: l12y, nsbeta1
Copied Ray's comments on bugscape bug: ------ Additional Comments From firstname.lastname@example.org 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.
I think this is a localization issue. "\\uxxxx" is treated as '\' and "uxxxx" whcih is a correct behavior.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID
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.
Tao, do you have suggestion? Can that be \n instead of \n\?
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.
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.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
I think Harish owns parser, cc to him. But this has to be resolved at string bundle level before getting to the parser.
Do you know who owns the string bundle handling?
Reassign to tao.
Assignee: nhotta → tao
Status: REOPENED → NEW
nsbeta1- L10N can workaround by combining into a single line
Keywords: nsbeta1 → nsbeta1-
Target Milestone: --- → Future
This bug should be closed now, since we had a fix in bug 144345.
FIXED per comment.
Status: NEW → RESOLVED
Last Resolved: 17 years ago → 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.