Closed Bug 352546 Opened 18 years ago Closed 16 years ago

Build Lightning with all locales included

Categories

(Calendar :: Lightning Only, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: mattwillis, Assigned: Fallen)

References

Details

Attachments

(3 files, 5 obsolete files)

As discussed in the 2006-09-13 calendar meeting, we're going to try to make Lightning 0.3 localized by including all completed localizations in the xpi at the time of launch.

If this can be scripted, so much the better.
Posting this here for posterity.  It's what I used to make all the lightning l10n jars.  Much easier that dealing with jar.mn/make insanity.
Lightning 0.3rc2 has all (completed) locales inside it.

-> WFM (since there's not really anything better to use)
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
Attached file Update script to work with 0.5 jars (obsolete) β€”
Updating this script to work with the 0.5 file set.
Attached file Fix 0.5 script (obsolete) β€”
fixes a couple errors in clint's version
Attachment #266562 - Attachment is obsolete: true
Attached file Fixed script for 0.5 RC2 β€”
Attachment #266566 - Attachment is obsolete: true
Regarding *release builds*, we should avoid any manual repackaging if possible; I'd like the tinderboxen to directly spit out l10n'ed xpis.
Status: RESOLVED → REOPENED
Flags: blocking-calendar0.7?
Resolution: WORKSFORME → ---
Target Milestone: Lightning 0.3 → 0.7
Attached patch lightning l10n (obsolete) β€” β€” Splinter Review
I have something that at least partially works, but still requires some attention. The way it is now, if you do |make TINDERBOX_L10N_VARIANT_N=1| in the lightning directory, all locales that are in /m/c/locales/shipped-locales will be built and added to the lightning.xpi before it it built. The two variants have the difference that VARIANT_1 *REQUIRES* all locales to have all files, while VARIANT_2 will probably ship an incomplete locale on error, since they are ignored.

The file /m/c/lightning/jar.mn has been split up. The original file only contains non-locale specific files, while the new file /m/c/lightning/locales/jar.mn contains all lightning specific locales and includes /m/c/locales/jar.mn for all calendar locales. The last file might need some work to take out or ifdef everything that is sunbird specific, but I'll leave that for later.

One open question is where/how we should package the locale stuff. I personally like this solution, where lightning specific stuff is kept in calendar/lightning, and just includes the main jar.mn, but w.r.t packaging this might not work out. Pike on #developerrs suggested the use of #ifdefs in calendar/locales and to just add that dir to lightning/Makefile.in's DIRS. This requires some major rework of calendar/locales/Makefile.in, but keeps the places where locale stuff is taken from at a minimum, and may allow lightning to work with the toolkit packager.

The next open question is how we want to control l10n being built for lightning. If we always package l10n, we obviously need to checkout the locale directory for each build, and depending on the above mentioned variant, the tinderbox will go red if something is missing. If we leave l10n packaging to the l10n tinderbox, then we probably only want a specific locale to be built, depending on the current language. This bug asks for packaging ALL locales though.

Currently, l10n packaging is done after the build by the tinderbox script. This means the (sunbird) zip/installer is taken apart, repackaged with the l10n stuff, and then put together again. The way I have made this patch creates the l10n files during the build process - after the build a finished l10n build comes out.

I'd be happy to hear some ideas on this patch, maybe someone else (lilmatt?) can help me complete this work.
Assignee: lilmatt → philipp
Status: REOPENED → ASSIGNED
Philipp, what is the current status on this bug? Have you spoken with ause or lilmatt about this?
lilmatt said he might be able to take a look on the last meeting, but he is busy with flock until at least the first week of october. I haven't asked ause.
Matt, Ause,
it would be really great if this issue could be fixed for 0.7. Is there any chance that you can take a look at Philipps patch and patch explanation in comment 7 and try to work out, how this can be fixed?
Flags: blocking-calendar0.7? → wanted-calendar0.8+
Target Milestone: 0.7 → ---
Version: Trunk → unspecified
Attached patch lightning l10n (obsolete) β€” β€” Splinter Review
De-bitrotted patch. Note I didn't test if lightning works with this patch, I just checked if the files are created in the right place and contain about the same thing.

Also, I probably exported a couple of vars too many, zip is being called after each dir. Probably because of USE_EXTENSION_MANIFEST. If possible this should not be exported, but I think it was needed for some reason.

I added a check for the l10n directory, which should be checked out in $(topsrcdir)/../l10n so our builds will behave nicely for non-tinderbox builds where the locale dir is not checked out.

Still left is also the decision which variant from the above comments we will choose.
Attachment #271424 - Attachment is obsolete: true
Attachment #294015 - Flags: review?(ause)
i don't pretend that i understand too much of this resource stuff, but i'm missing the localized versions of calendar-en-US.jar in the xpi.

the last files in the patch are missing "mozilla/calendar" in the filenames. easy to workaround once you find it ;)

i'd prefer variant 1 - if we build localized .xpi from a selected list of locales to be shipped, i'd like to see occuring errors...
Flags: wanted-calendar0.8+ → blocking-calendar0.8+
Attached patch lightning l10n - v3 (obsolete) β€” β€” Splinter Review
This should also take care of calendar-@AB_CD@.jar
Attachment #294015 - Attachment is obsolete: true
Attachment #295925 - Flags: review?(ause)
Attachment #294015 - Flags: review?(ause)
Attached patch lightning l10n - v4 β€” β€” Splinter Review
Build only checked out locales, but not those we don't ship.
Attachment #297316 - Flags: review?(ause)
Attachment #295925 - Attachment is obsolete: true
Attachment #295925 - Flags: review?(ause)
Attachment #297316 - Flags: review?(ause) → review+
Checked in on HEAD and MOZILLA_1_8_BRANCH

-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 18 years ago16 years ago
Resolution: --- → FIXED
Target Milestone: --- → 0.8
IMHO this is a very bad idea, you should have gone with dependent localization packs instead, like ChatZilla and venkman do :(
Comment on attachment 297316 [details] [diff] [review]
lightning l10n - v4

>+l10n_locales := $(filter-out CVS,$(notdir $(wildcard $(topsrcdir)/../l10n/*)))

This assumes that every subdirectory of l10n/ contains a full calendar localization, which is just plain wrong.
Could this fix be the causer for Bug 413868?
Depends on: 413868
Checked issue with latest build -> task is fixed and verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.