Closed Bug 307225 Opened 16 years ago Closed 16 years ago

Language packs for Firefox 1.5 Beta need chrome.manifest files in order to install


(Core :: Internationalization: Localization, defect)

1.8 Branch
Not set





(Reporter: twanno, Assigned: Pike)




(Keywords: fixed1.8)


(6 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050905 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050905 Firefox/1.0+

Currently language packs won't install in recent 1.0+ branch builds, because of
a failed chrome registration. This is because the language packs don't contain
contents.rdf files anymore. 

When I manually add a chrome.manifest file based on the install.rdf file (and
raise the em maxVersion to 1.0+), the language packs install without any problem.

Further more, according to the install.rdf specs at an
em:type entry has to be specified in the install.rdf file (type=8 for
localizations), but I don't think leaving that out will not install the language

Reproducible: Always

Steps to Reproduce:
1. download language pack from given url
2. manually raise the maxVersion to 1.0+ in install.rdf so it will install in
recent 1.0+ nightly
3. drag and drop modified xpi in browser, so it will install
4. restart Firefox 
5. Notice chrome registration failed error

Actual Results:  
Language pack will not install with error dialog saying that chrome registration

Expected Results:  
chrome registration should be succesfull

When a chrome.manifest file is added to the language pack, the em:file
information in install.rdf could be removed, because that is not necessary anymore.

BTW: I use the language packs to test localizations of my extensions, so I don't
have to download several different localized builds.
With this chrome.manifest file added to the French (fr) language pack, and a
modified install.rdf (which I will attach next), the language pack installed
without a problem
In this file I commented out the em:file declaration, because with a
chrome.manifest file this is not necessary anymore.

I also added this line <em:type>8</em:type> to show it is a localization.

And I raised the maxVersion to 1.4 (so it will work when the version of Firefox
is raised to 1.4). Apart from the last step, these modifications are not
necessary to install the language pack correctly in the latest
mozilla1.8-branch Firefox nightly
Attachment #195015 - Attachment mime type: application/rdf+xml → text/plain
Component: Other → Localization
Product: Mozilla Localizations → Core
Version: unspecified → 1.8 Branch
changing from Product: Mozilla Localizations, Component: Other to Product: Core,
Component: Localization, because I think it's better off here.

And asking blocking 1.8b5, as I think this should be fixed before Firefox 1.5
comes out and I can't ask for blocking-aviary1.5 here.
Flags: blocking1.8b5?
I'll be driving this, patch coming up. It'd be good to have this on the branch,
This is merely l10n language packaging build foo, so no l10n impact per-se.
Assignee: nobody → l10n
Ever confirmed: true
CCing localizers, though there is no l10n impact codewise, this is still 
OS: Windows XP → All
Hardware: PC → All
This patch does the following fixes to the generic install.rdf:
It removes the obsolete em:file stuff, add em:type and uses @MOZ_APP_VERSION@
em:minVersion and maxVersion, as the build is checking for compatibility

In addition, I added a USE_EXTENSION_MANIFEST=1 to the phase that builds the
langpacks, so that chrome.manifest is generated (it looks like the one
and pack that generated file, those are the changes to
Attachment #196307 - Flags: review?(gandalf)
Comment on attachment 196307 [details] [diff] [review]
fix language pack building

Attachment #196307 - Flags: review?(gandalf) → review+
fix landed on the trunk, letting it smoke for a bit.
Closed: 16 years ago
Resolution: --- → FIXED
Flags: blocking1.8b5? → blocking1.8b5+
Backed out the part, as that busted macs.

I'd be thankful if someone could run make -n with the modified makefile and 
compare that to, as that
does give -c l10n-source, which the macs complain about.
is an example build log of the bustage (not special to da, other builds at
the time are busted the same way).
Flags: blocking1.8b5+ → blocking1.8b5?
Resolution: FIXED → ---
Flags: blocking1.8b5? → blocking1.8b5+
Axel, we need to get this in the branch ASAP. Is it ready to go?
macs refused to give a profound reason for the error message so far, I'll provide
a patch that just disables the chrome.manifest building for the mac, unless
bsmedberg has a cycle to investigate. I looked at a log of make -n, and even on
a mac, the locale dir argument is given. May be escaping or file path fun or
whatever, I'll need a mac to do some perl -d.

Anyway, if the locale xpis built on mac don't make nice langpacks, that's not too
*** Bug 309716 has been marked as a duplicate of this bug. ***
I want benjamin to review this, this is his baby and I hack it.
Attachment #197170 - Flags: review?(benjamin)
Not sure, if it is related to this bug:

<maxversion> is still set to 1.1 in latest langpacks.

This should be the coresponding version (1.4 at this time) to the relating binaries.
Comment on attachment 197170 [details] [diff] [review]
build and ship chrome.manifest for all but macs

Well, that's more than a little weird, and it should probably be investigated.
But the hack-solution ought to be to ifdef so that
we don't try to make the langpack at all on mac.
Attachment #197170 - Flags: review?(benjamin) → review-
Re #14, this bug isn't fixed for mail at all,

Benjamin, I need someone with a mac and perl debugger time to solve this right
for 1.5.
Hacking the langpack out of there is more intrusive than justified, IMHO,
as we call the libs phase there. I do expect to have a mac at my disposal post
1.5, too, and I plan to pick this up then.

As we're talking, I would like to set max and minor version of the langpack to
the branch base version and the branch head version, respectively. Something
equivalent to 1.0 and 1.0.7. Any idea for that?
Attachment #197705 - Flags: review?(l10n) → review+
Attachment #197705 - Flags: approval1.8b5?
Attachment 197705 [details] [diff] checked in on trunk.
Comment on attachment 197705 [details] [diff] [review]
Process the "-e" option to correctly [checked in on 1.8 branch]

Approved for 1.8b5.
Attachment #197705 - Flags: approval1.8b5? → approval1.8b5+
Attachment #197705 - Attachment description: Process the "-e" option to correctly → Process the "-e" option to correctly [checked in on 1.8 branch]
Relanded the backed out part of attachement 196307, thanks to bsmedberg for 
finding the bug in

Leaving open for the mail part of this.
Comment on attachment 196307 [details] [diff] [review]
fix language pack building

Requesting approval, this is a l10n langpack-only change that does not require
interaction from l10n owners.

Now that the trunk and the branch have the required fix, this is low risk.
Attachment #196307 - Flags: approval1.8b5?
Comment on attachment 196307 [details] [diff] [review]
fix language pack building

do we need to make these same changes to Thunderbird? If so, can we get a patch
here or in a new bug please? thanks.
Attachment #196307 - Flags: approval1.8b5? → approval1.8b5+
Attachment #198010 - Flags: review?(benjamin)
Attachment #198010 - Flags: review?(benjamin) → review+
Attachment #198010 - Flags: superreview?(mscott)
Attachment #198010 - Flags: superreview?(mscott)
Attachment #198010 - Flags: superreview+
Attachment #198010 - Flags: approval1.8b5+
Fixed for both thunderbird and firefox on both trunk and 1.5 branch.
Closed: 16 years ago16 years ago
Keywords: fixed1.8
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.