install of italian language pack succeeds but says chrome registration failure and language is not available after restart

RESOLVED FIXED in mozilla1.0


Mozilla Localizations
it / Italian
16 years ago
16 years ago


(Reporter: mrgrimm, Assigned: Andrea)



Firefox Tracking Flags

(Not tracked)




(1 attachment)



16 years ago
upon installing italian language pack, after directions come up (in italian) for
setting the language to italian, a box says chrome registration failed and
italian is not available language pack after restart

Comment 1

16 years ago
Sorry, can't reproduce.
Are you sure having done a _clean_ Mozilla installation? I mean, have you
deleted the .mozilla folder on your profile before using the new version?

Please try to clean everything, reinstall and try again.

I'd also like some more info like the distribution you're running Mozilla on,
the kernel version, if you installed the lang pack logged as user or super-user,
from where did you installed the lang pack.. and anything else you think it
might be worth to mention.

If you can, please attach the install.log file you should find either on your
mozilla folder or in your profile .mozilla/ folder (this folder is hidden).

Comment 2

16 years ago
Created attachment 82357 [details]
Reperte's install log

Comment 3

16 years ago
In the install log I can see some "Access denied" errors.
Could you report the permissions set for the chrome/ and defaults/profile/ 
folders ?

*** This bug has been marked as a duplicate of 109044 ***
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
hang on, made a mistake here, repoening
Resolution: DUPLICATE → ---

Comment 6

16 years ago
The bug is on the lang pack install script.
It needs to fail gracefully if the user can't access the bin/defaults/ folder in
a multi user enviroment.
Ever confirmed: true
Target Milestone: --- → mozilla1.0

Comment 7

16 years ago
Resuming what's going on:

The user uses a build owned by root, with no access to the folders under

The Italian lang pack normally detects the inability to write in these folders (
-202 = access denied). Then install script reset the error condition, and it try
to install inside the user profile. There, the files are normally copied.

Somehow then then the copied components fail to register ( -239 = registry error).
I could suspect this is due the inability for the mozilla process - now owned by
user (right?) - to write access the registry files, root owned.

Looking through the attached user's install.log, it seems the Asturian language
pack, and then the Asturies contents pack, after going through basically the
same steps, *succeeds* on registering the components copied in the profile folders.

I have no clue the reasons why :\\

I really think there might be a link between this bug and bug 109044. (But pls
don't resolve it as a dupe if don't have a clue about the causes)

Comment 8

16 years ago
In the attached install.log file, you see the installation of my German pack as
the last entry. The default XPI of MT5beta8 should look simialr, and the user
gets an alert telling him that he needs write permissions to the mozilla main

The real problem is that we need to install with DELAYED_CHROME (via
installed-chrome.txt) on unix due to bug 109044 and DELAYED_CHROME does not work
with an install in the profile directory.
So we only can install in the profile directory on win and mac platforms (the
MT5beta8 script checks for this and does it), but not on unix where we would
potentially need that most :(

Due to that reasons, I'd think it will be best to mark this one dependent on bug
109044 - but it's your bug, so you should do/decide that...

Comment 9

16 years ago
Yes. I'm marking this bug as fixed.
I'm removing the completely the DELAYED_CHROME switch from my RC2 and RC3 lang
packs, waiting in bug 109044 for someone else confirming the bug is still valid.

Comment 10

16 years ago
Changing the resolution as FIXED.
Please add your comment here if you think this is not the case.
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.