144345 - "hardcoded" wrapping in the string makes localization difficult

Status: VERIFIED FIXED

(SeaMonkey :: General, defect)

Description

[Ying-Lin Xia]

Can we remove all the line breaks inside the properties strings? It makes 
localization very difficult:

en-US.jar\locale\en-US\messenger\messenger.properties:

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.

nocachedbodytitle=<TITLE>Go Online to View This Message</TITLE>\n\

Comment 1

[tao]

Hi, Ying: 

The line breaks are used to indent/format the strings in the UI (dialog?). Is
there another way to indent the strings?

Comment 2

[Ying-Lin Xia]

Why we *only* have the line breaks in this string, what's the reason?

Comment 3

[David :Bienvenu]

no, this message is displayed in the message window, not a dialog, when the user
is offline and clicks on a message header of a message that has not been
downloaded for offline use. This was just copied over from 4.x - we could try it
without the \n's and see how it looks. I'm unclear why localizing it is a
problem. If you want to localize it without the \n's, why not just do that?

Comment 4

[Ying-Lin Xia]

two reasons:
1) Without detail infor, translators won't know where to break lines, different languages have different line break rules, not just like English break with spaces.
2) With the symbol "\n", our localization tools have some difficulties to match the string in the translation memory. So the vendor needs to work on this kind of stuff manually, everytime.

Comment 5

[David :Bienvenu]

Attachment: remove /n's

Comment 6

[David :Bienvenu]

checked in r/sr = sspitzer

Comment 7

[Michele Carlson]

Need Adt's approval to check this into the branch. Am I reading it correctly
that this has been r/sr and has been checked into the trunk already?

adding nsbeta1

Comment 8

[David :Bienvenu]

it's checked into the trunk - I thought we were long past the point where we
could check in resource/ui changes into the branch...

Comment 9

[Michele Carlson]

UI freeze for RTM is on June 3rd. So we're okay for UI changes until then. 

Comment 10

[Ying-Lin Xia]

Can you please check this into the commercial branch? There is no UI change here...

Comment 11

[David :Bienvenu]

what's the commercial branch? If you mean the 1.01 branch, I need approval from
the adt before I can checkin. The bug is nominated, but nothing beyond that.

Comment 12

[Michele Carlson]

nominating it for adt2 rtm

Any chance we can get this approved by Adt for check in to the branch?

Comment 13

[Paul Wyskoczka]

Marking adt1.0.1+ on behalf of the adt for checkin to the 1.0 branch.  Please
get drivers approval before checking in.

Comment 14

[Judson Valeski]

please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.

Comment 15

[David :Bienvenu]

checked into branch.

Comment 16

[lchiang]

[e-mail] - can you verify this bug fix in branch?  When verified, pls
replace fixed1.0.1 keyword with verified1.0.1.  Thanks.

Comment 17

[Ying-Lin Xia]

The fix only checked in 1.0 branch, not trunk. Should we still close it?

Comment 18

[[e-mail] (gone - use [e-mail] instead)]

It actually was checked into the trunk. See
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=messenger.properties&root=/cvsroot&subdir=mozilla/mailnews/base/resources/locale/en-US&command=DIFF_FRAMESET&rev1=1.72&rev2=1.73

Therefore, this could easily be verified on the trunk and branch.

Comment 19

[Ying-Lin Xia]

No you didn't ;-) In today's Mozilla and Netscape trunk build, the line breaks
are still there...

Comment 20

[Ying-Lin Xia]

Sorry, my bad, looked on wrong files :-(

Comment 21

[Ying-Lin Xia]

verified.

Comment 22

[David :Bienvenu]

it looks fine to me.