similar to bug 279768.

I don't know why it shows me as taking away 286110, so I am putting it back. Must have been a hiccup in the software.

No· This bug does not depends on Seamonkey one.

Sasquatch Bigfoot had somehow changes it from blocking the SeaMonkey one to being blocked by the SeaMonkey one, what is wrong. Re-setting this as blocking the SeaMonkey bug, as it was in the start, and what I still think is correct.

Mscott already landed a change that builds these files from mail/locales, but he never stopped building them from mailnews. Fix that.

Comment on attachment 177625 [details] [diff] [review] Stop building MAPI locale files from mailnews/ I'm pretty sure I checked this change in when I did the work and CVS is telling me that I did indeed fix this when I checked in, is your tree not upto date? http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&f ile=jar.mn&branch=&root=/cvsroot&subdir=mozilla/mailnews&command=DIFF_FRAMESET& rev1=1.91&rev2=1.92

(In reply to comment #3) > Sasquatch Bigfoot had somehow changes it from blocking the SeaMonkey one to > being blocked by the SeaMonkey one, what is wrong. > > Re-setting this as blocking the SeaMonkey bug, as it was in the start, and what > I still think is correct. I don't think I changed it the first time, so that is the reason I changed it back . If it is wrong now, I'm not touching. Hope that explains it. Sorry for the extra commentary.

ummm excuse me but did we some how forget to ask for a module owner review and sr here before changes to mozilla\mail were checked in? I'm not even cc'ed on the bug!

Scott, I was under the impression that I was allowed to review these locale-moving and locales-in-CVS patches. I am happy to get a second review if that's what you need, but we need to move relatively quickly to get this all finished.

Scott: I also wrote to you about my current work more than month ago, asking about some of issues I'd like to fix. You did not respond me, so I was sure you're not interested in this subject.

This patch excludes navigator and most of ./components which are already forked or aren't used by Thunderbird.

Comment on attachment 179186 [details] [diff] [review] ifdef xpfe navigator most of components for Tb Why did you leave some of the prefwindow stuff? Are you going to need to fork those files?

I left some of prefwindow and some of alerts stuff because those files were bundled in Thunderbird 1.0. I asked Scott if those are needed. If those are needed, I can leave it like in this patch or fork into mail/locales/chrome/en-US/xpfe - I also asked Scott for decision.

Comment on attachment 179186 [details] [diff] [review] ifdef xpfe navigator most of components for Tb the trunk has a brand new options dialog so I don't think we need any of the old pref files. We get all of our alert packaging from toolkit so we shouldn't need any of these either.

Ok. I'm checkin this patch with ifdefing whole ./components. I tested it quite a lot on Windows and Linux, and there should be no regression.

checked in.

This patch will ifdef not used extensions/wallet.

Why not just stop building xpfe/browser for thunderbird? That would be much cleaner then the jar.mn ifdefs.

(In reply to comment #19) > Why not just stop building xpfe/browser for thunderbird? That would be much > cleaner then the jar.mn ifdefs. And it would assure us (seamonkey project) that we can waste around with everything in there without caring for anyone else. Which would be very assuring, as we definately would like to clean up some one the mess that's around in the whole xpfe/ directory currently and at least move all our chrome around at some point (might be post-Gecko-1.8 cycle though).

I'm OK with this. Mscott? Benjamin?

The c++/interfaces in xpfe/browser are used by Firefox and are built as part of the toolkit.

I was only talking about not building xpfe/browser for thunderbird, and did not suggest to change anything for firefox.

If there is a part of toolkit from xpfe/browser, I think it should be in every toolkit based app.

Should mail/components/compose/content/autocomplete.xml start being packaged now? Looks like ifdef'ing xpfe/components/jar.mn broke composition autocomplete. XML Parsing Error: no element found Location: jar:file:///C:/PROGRA~1/Mozilla/THUNDE~1/chrome/mail.jar!/content/global/autocomplete.xml Line Number 1, Column 1: Why was tb relying on the xpfe autocomplete.xml version?

Scott: Why are we using xpfe autocomplete if you already forked it to mail/components? 1) http://lxr.mozilla.org/seamonkey/source/mail/config/mail-jar.mn#148 2) http://lxr.mozilla.org/seamonkey/source/mail/components/compose/jar.mn 3) http://lxr.mozilla.org/seamonkey/source/mail/components/compose/content/

we use xpfe's autocomplete....I don't know what the files you pointed to are. CVS says they were added by blake as an experimental widget in 2002.

we use lots of stuff like autocomplete in xpfe\components. Did your patch really stop packaging up all of that stuff? That's going to break lots of stuff as pointed out by Stephen Walker. I thought the patch was only ifdefing out pref files and pref locales. I didn't notice a patch that got rid of all xpfe\components, that would be very bad!

I ifdefed whole jar.mn in components. Which of those files are used by Tb? http://lxr.mozilla.org/seamonkey/source/xpfe/components/jar.mn

Comment on attachment 179379 [details] [diff] [review] ifdef mozilla/extensions/wallet Did we fork the content files, or only the locale files from wallet? I'm pretty sure tbird still uses the wallet code, unless things have changed since 1.0.

Scott backed out components part. Scott: is there anythingbeside autocomplete that needs to stay?

hmm it's possible autocomplete.xml and autocomplete.css are the only two chrome files we use anymore from there. Mayb ethe find dialog code but I'd have to test it on a clean build to be sure.

Comment on attachment 179379 [details] [diff] [review] ifdef mozilla/extensions/wallet Ok. I'll check a finddialog today and I'll send a new patch. Also - I'll prepare new patch for wallet since this one ifdefs wallet's content resources which are used (Scott?) by Tb

finddialog is in toolkit/content: http://lxr.mozilla.org/seamonkey/source/toolkit/content/jar.mn#24 and autocomplete in toolkit/content/widgets: http://lxr.mozilla.org/seamonkey/source/toolkit/content/jar.mn#36 The new patch uses only autocomplete from xpfe (since it is in Tb 1.0). Scott - can we use only toolkit autocomplete.xml ?

(In reply to comment #34) > Scott - can we use only toolkit autocomplete.xml ? Actually, we can't. They are completely different implementations and not just forked files in this case.

Comment on attachment 180168 [details] [diff] [review] components part I just tested this on a clean build and it passed smoketests for me on windows.

Comment on attachment 180168 [details] [diff] [review] components part Description for driver: this patch will remove unused data from Thunderbird which is not localizable at the moment.

this patch removes locales from building with Thunderbird. Those are not needed nor localizable.

Comment on attachment 180633 [details] [diff] [review] extensions/wallet/jar.mn ifdef I verified that we've already forked the SignonViewer properties file which we still use. So we should be ok on that front.

Comment on attachment 180633 [details] [diff] [review] extensions/wallet/jar.mn ifdef There is a typo - ifdef instead of ifndef. I fixed it locally

This patch removes ./xpfe/communicator locales from Tb and forks communicator-platform bits to mail/locales.

Mscott, do you have any time to update the patch in bug 250311?

Comment on attachment 180644 [details] [diff] [review] Remove xpfe/communicator bits and fork communicator-platform ones I got rid of communicator-platform a while ago. See Bug #285510. We don't use it anymore so we should have to fork it.

Comment on attachment 180633 [details] [diff] [review] extensions/wallet/jar.mn ifdef a=asa

Comment on attachment 180644 [details] [diff] [review] Remove xpfe/communicator bits and fork communicator-platform ones a=asa

Mscott: it looks for me that Tb uses xpfe/global ab-plat.jars. (http://lxr.mozilla.org/seamonkey/source/xpfe/global/jar.mn#114) Is that true? If so, can I move Tb to use the ones from toolkit?

(In reply to comment #46) > Mscott: it looks for me that Tb uses xpfe/global ab-plat.jars. > (http://lxr.mozilla.org/seamonkey/source/xpfe/global/jar.mn#114) Is that true? > If so, can I move Tb to use the ones from toolkit? I didn't quite understand what you mean here. what are ab-plat.jars? Sorry!

(In reply to comment #47) > I didn't quite understand what you mean here. what are ab-plat.jars? Sorry! ab-<platform>.jar (like en-win.jar)

yeah go ahead and move us to the platform stuff in toolkit. Thanks!

Ok. Updated patch, this should make the deal. I'm willing to finish this work asap

Comment on attachment 181761 [details] [diff] [review] Remove xpfe/communicator bits So, we don't need platformCommunicatorOverlay? Or we're getting it from somewhere else?

It's Comment #43. I'm testing Tb without xpfe/global locales and it works fine for me. Another issue is that I'm not ifdefing resource files, and it looks that _many_ of them are not used (from xpfe/*/jars.mn). Investigating resource files from xpfe/* could be a nice codesize win.

I removed those bits, and Tb works smoothly. I also checked lxr against those files, and it seems to be OK to remove them.

Comment on attachment 181761 [details] [diff] [review] Remove xpfe/communicator bits I ran through the smoktests with this patch on Windows and everything looked fine.

Comment on attachment 181776 [details] [diff] [review] remove xpfe/global jars I ran through the smoketests with this patch and everything looked fine on Windows.

Comment on attachment 181761 [details] [diff] [review] Remove xpfe/communicator bits a=asa

Comment on attachment 181776 [details] [diff] [review] remove xpfe/global jars a=asa

checked in communicator and global patches.

Comment on attachment 181776 [details] [diff] [review] remove xpfe/global jars ex-post-facto r+

http://lxr.mozilla.org/mozilla/source/mailnews/extensions/mailviews/resourecs/content/mailViews.dat should be a localizable file, forked into mail/locales I guess.

The special RSS account file should be also localizable http://lxr.mozilla.org/mozilla/source/mail/extensions/newsblog/rss.rdf

This is basically a copy of the l10n build scripts that we use for Firefox, odified as appropriate. They seem to create en-US builds that work fine.

Comment on attachment 183307 [details] [diff] [review] Localized installer packaging, rev. 1 [checked in] all-l10n.js has Firefox in the license. I think these should drop the 'Mail' part: +Component_RSS_Long=Adds RSS support to $ProductName$ Mail. Component_Offline_Long=Adds Offline support to $ProductName$ Mail.

Comment on attachment 183307 [details] [diff] [review] Localized installer packaging, rev. 1 [checked in] a=asa

Comment on attachment 183307 [details] [diff] [review] Localized installer packaging, rev. 1 [checked in] Landed on trunk, with removed "mail" from $ProductName$ mail. The "original code is Firefox" is correct, because I copied that file from the browser code. The only big thing left that I know of is adding preprocessing to the mail/config repackaging step to create mail-locales.manifest correctly.

Benjamin, what can I do to Patrocles to give it iconv so it goes green again? Is this a cygwin tool?

Yeah, you install "libiconv" from the cygwin installer. I already sent an email to Chase/dbaron about it, so you might want to check with them.

(In reply to comment #67) > Yeah, you install "libiconv" from the cygwin installer. I already sent an email > to Chase/dbaron about it, so you might want to check with them. I installed iconv on patrocles. I was careful not to upgrade other packages but it's possible something in the build may break. I'll keep an eye on it.

Chase, I think another package may have gotten updated accidentally as the change broke the build machine: configure: error: The linker major version, , does not match the compiler suite version, 6. *** Fix above errors and then restart with "make -f client.mk build"

That error is due to the cygwin upgrade. To fix, move /bin/link to /bin/link-cygwin (we do not need that file for our builds).

(In reply to comment #70) > That error is due to the cygwin upgrade. To fix, move /bin/link to > /bin/link-cygwin (we do not need that file for our builds). FYI, I just made that change on Patrocles.

(In reply to comment #70) > That error is due to the cygwin upgrade. To fix, move /bin/link to > /bin/link-cygwin (we do not need that file for our builds). The solution I've been using for this problem as it hits certain machines is to change how PATH is composed in the Cygwin shell. I altered patrocles to use that fix and renamed /bin/link to avoid any future packaging problems we might run into with it down the road.

This is the last patch needed for Tb source l10n. It removes ldap.properties and tasksOverlay.dtd. We have ldap.properties forked already. Bigger problem is with tasksOverlay.dtd. It is used in: 1) http://lxr.mozilla.org/seamonkey/source/xpfe/communicator/resources/content/tasksOverlay.xul#5 2) http://lxr.mozilla.org/seamonkey/source/editor/ui/composer/content/editorTasksOverlay.xul#38 I'm not sure if we use the second and we probably don't use the first one. Mscott: can you confirm?

Comment on attachment 183766 [details] [diff] [review] last patch (ldap and tasksOverlay.dtd) Requesting approval for 1.1a1. this is the last patch that will give us full Tb source l10n.

Comment on attachment 183766 [details] [diff] [review] last patch (ldap and tasksOverlay.dtd) This can wait until after a1, we're still cleaning up from xpcnativewrappers and we need to get a release out.

I'm configuring l10n builds for Thunderbird as we speak. The build halts early due to the missing mail/locales/all-locales file. I'd like to create this file. I presume once it's present the build will proceed as normal even if there are no locales in it -- we'd just not be building any locales for Thunderbird until they are added later. Any objections?

sounds ok to me chase.

Added the all-locales file on the trunk: RCS file: /cvsroot/mozilla/mail/locales/all-locales,v done Checking in all-locales; /cvsroot/mozilla/mail/locales/all-locales,v <-- all-locales initial revision: 1.1 done

My build is proceeding as expected after adding the mail/locales/all-locales file.

updated to trunk.

Comment on attachment 185981 [details] [diff] [review] updated patch [checked in] Checking in xpfe/communicator/jar.mn; /cvsroot/mozilla/xpfe/communicator/jar.mn,v <-- jar.mn new revision: 1.40; previous revision: 1.39 done

A quick status report: I spent time this week rationalizing the resources needed for l10n builds and configured the three l10n systems we have to produce nightly builds for three products: * Firefox on the Aviary 1.0.1 branch * Firefox on the trunk * Thunderbird on the trunk While in the build scripts I did some clean-up and checked what changes I had back in. I verified that builds on all three products on all three platforms run to completion. I plan to coordinate next week with bsmedberg and gandalf for what's needed to quell any remaining locale issues in build config. Can either of you describe the remaining tasks? From what I saw last week there appears to be work needed on the repackage target and sorting out Thunderbird filenames (so they use the same format Firefox uses). I wonder how many/which locales are ready to be placed in Thunderbird's all-locales file, too.

> I wonder how many/which locales are ready to be placed in Thunderbird's > all-locales file, too. 7 (ca, cs, fi, hu, nb-NO, nl, ru) locales are ready. http://wiki.mozilla.org/L10n:Thunderbird_1.1.x_Status

sv-SE is also ready now.

(In reply to comment #82) > Can either of you describe the remaining tasks? On my side, I need to check all files packaged to jar to see if those are used and make my work in bug 295465. > I wonder how many/which locales are ready to be placed in Thunderbird's > all-locales file, too. Many. Pavell pointed some of them, others need to update a few strings.

I added ca, cs, fi, hu, nb-NO, nl, ru, and sv-SE to Thunderbird's all-locales file.

Comment on attachment 186208 [details] [diff] [review] Remove/change double entities [checked in] we want to remove duplicated entries to make tinderbox (compare-locales) happy.

Comment on attachment 186208 [details] [diff] [review] Remove/change double entities [checked in] a=me for l10n changes

Note for Gandalf at his request: In mailnews/base/ispdata is file called movemail.rdf, which is used by linux Thunderbird builds and it has two lines that needs to be transtaled.

Comment on attachment 186208 [details] [diff] [review] Remove/change double entities [checked in] thanks Pavel!

bsmedberg/gandalf: who will be biting off reworking package naming for Thunderbird's build config so that it operates how Firefox's package naming works? Do you need extra resources to make that happen?

Package naming is in fact quite trivial, patch upcoming.

This is blocking-aviary1.1. Marking it as such.

no need to nominate a bug that I've already put in the 1.1 milestone list. That means I've already made it a blocker :)

Comment on attachment 186508 [details] [diff] [review] Use "en.lproj" instead of "English.lproj", like Firefox, rev. 1 [checked in] r=mano

Comment on attachment 186508 [details] [diff] [review] Use "en.lproj" instead of "English.lproj", like Firefox, rev. 1 [checked in] a=chase

In the l10n mac builds on http://ftp.mozilla.org/pub/mozilla.org/thunderbird/tinderbox/latest-trunk-l10n/ is the dir editor missing in the XX.jar (if this is not the right bug to report this; i am sorry)

Comment on attachment 186580 [details] [diff] [review] Add editor/ui to the LOCALES_mail list This is not enough. We're not *building* editor/locales from mail/locales/Makefile.in like we should, it needs to be added to the libs-% target with the line @$(MAKE) -C ../../editor/ui/locales AB_CD=$* XPI_NAME=locale-$* (add this before line 77).

It seems that attachment 180633 [details] [diff] [review] to remove wallet files from Thunderbird was never checked in. Has it been forgotten?

gandalf, are we ready to close this bug out?

Yes. I think that we can. There are minor bugs like bug 299483 and bug 223292 that can be fixed later. Marking as FIXED - hoah! :)