102766 - Please move localizable mapi files to en-win.jar

Status: VERIFIED FIXED

(MailNews Core :: Simple MAPI, defect, P4)

Description

[tao]

Looking at the MAPI_SUPP_BRANCH, I found that there are two localizable files,
"mapi.properties" and "pref-mailnewsOverlay.dtd", in
"mozilla/mailnews/mapi/resources/locale/en-US", and will be packaged into
en-US.jar!chrome://messenger/locale/.

If MAPI is Windows only feature, the UI strings should live in en-win.jar
instead of en-US.jar.

Comment 1

[Jaime Rodriguez, Jr.]

Pls "nsbranch-", if we are not gonna fix this one in the branch.

Comment 2

[Tiantian Kong]

This issue has been resolved through email discussions. Copied the emails here.
(will fix after 0.9.4.)


Srilatha Moturi wrote:

Ok then. I will not move them now. 
Srilatha 
Michele Carlson wrote: 

Yes - I agree with Ray. Please do not move files at this point. 
thanks. 
Michele 


Ray Chen wrote: 

There could be a potential problem for L10N. Moving the files around would cause
the file path mismatch and could not be leveraged properly.  At this moment (UI
freeze already), it is better not to change it. Since these two files are so
small (about 10 strings), leaving them in en-us.jar won't harm. You can fix it
after 0.9.4. 
Thanks, 
- Ray 

Tao Cheng wrote: 

Since there is no impact on the regus.xpi (US.jar), I am fine with the change.
It's L10n group's call whether we accept moving files from en-US.jar to en-win.jar. 
As to moving files from en-US.jar to en-win.jar, see my comment below.

 
Michele Carlson wrote: 

If the files have been in the branch since 9/17 we should be fine from a l10n
point of view. The UI has already been translated. 
thanks 
Michele 


Srilatha Moturi wrote: 

These files are on the  0.9.4 branch for a while now (checked in on 9/17). 
I did not know about en-win.jar. I can make the change.The changes will be in
jar.mn file so I'm guessing this should not effect localization at all.
In addition to the jar.mn change, you'd need to 
update the chrome urls referencing the dtd and property file from
chrome://messenger/locale/* to chrome:://messenger -platform/locale/* 
create a new package, "messenger-platform" 
update makefiles and installer script to reflect the changes in chrome registry. 
make sure that the en-win.jar on Mac and Linux contains the MAPI files. 
QA the change.... 

-


Tao 

Comment 3

[Tiantian Kong]

Mark as depedent to meta bug 103807

Comment 4

[Srilatha Moturi]

Attachment: patch v1

Comment 5

[Srilatha Moturi]

Attachment: updated the version number

Changed the locale version to 0.9.6

Comment 6

[Srilatha Moturi]

ccing Seth and Bhuvan for sr and r

Comment 7

[racham]

r=bhuvan

Comment 8

[(not reading, please use [e-mail] instead)]

Comment on attachment 57663 [details] [diff] [review]
updated the version number

seems ok to me. 

do you need to make similar changes to the netscape commercial tree?

Comment 9

[Srilatha Moturi]

No, Changes in the commercial tree are not necessary because there is no 
mapi/locale directory in the ns tree and also there is not need to override 
contents.rdf (since there is no existing contents.rdf in the mailnews directory  
for messenger-platform)

Comment 10

[tao]

Since there was no messenger-platform package before, you want to register it in 
makefiles so the new package could be recognized in development builds. Same things
apply to installer scripts so commercial builds work as expected.

Comment 11

[Srilatha Moturi]

Attachment: updated patch against the trunk

Updated the patch against the trunk. Since messenger-mapi package was already
created, using that instead of creating "messenger-platform".

Comment 12

[(not reading, please use [e-mail] instead)]

is that last patch complete?   second patch has other changes.

Comment 13

[Srilatha Moturi]

Yes it is complete, since the contents.rdf for messenger-mapi, changes in 
pref-mailnewsOverlay.xul and jar.mn already exist in the trunk. These were 
checked in by mscott. see bug # 112724

Comment 14

[racham]

r=racham.

Comment 15

[(not reading, please use [e-mail] instead)]

Comment on attachment 64397 [details] [diff] [review]
updated patch against the trunk

sr=sspitzer

Comment 16

[Srilatha Moturi]

Fix checked in

Comment 17

[Trix Supremo]

marking verified