gu-IN and pa-IN uninstall broken after update (Windows, FF+Tbird)

RESOLVED WONTFIX

Status

()

Toolkit
Application Update
RESOLVED WONTFIX
12 years ago
10 years ago

People

(Reporter: tracy, Unassigned)

Tracking

({regression, smoketest})

1.8.0 Branch
x86
Windows XP
regression, smoketest
Points:
---
Bug Flags:
blocking-firefox2 -
blocking1.8.0.4 -
blocking1.8.0.5 -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

12 years ago
if you update from Thunderbird from 1.5 to 1.5.0.2, the gu-IN and pa-IN unistallers are broken.

The straight installed versions of 1.5 and 1.5.0.2 uninstallers for those locales work fine.

-install 1.5
-update to 1.5.0.2

tested results:
The add/remove item for Thunderbird 1.5.0.2 has been localised and fails to work. It can't find the uninstall log file.
Also, manually running the unistaller from the app dir fails

Expected results:
The add/remove item shows as unlocalised Thunderbird 1.5.0.2 and unistalling works endign with bringing up the new survey dialog.

Didn't know where else to file this, Axel suggested here.

Comment 1

12 years ago
The suspect #1 mentioned on #developers is nsPostUpdateWin.js, updateRegistry.

This pulls the brandFullName from brand.properties to set the registry key.
Which, at least that is the idea I have right now, is inconsistent with what
the installer and the uninstaller think.
That's why installers uninstall fine, updates don't, *IFF*:
the localization of brandFullName is not what the installer expects, which is
perfectly fine in the rest of the app.

Candidates for affected products/locales:
Thunderbird 1.5.0.x: gu-IN, pa-IN
Firefox 1.5.0.2: ar, be (not released), gu-IN, pa-IN

For the Thunderbird builds, both gu-IN and pa-IN show the problem, and are
the only two locales that changed fullBrandName, tested with the releasetest 
update channel. The Firefox list is just a grep in the source to check possibly 
affected builds.

This is not a bug in the localizations for sure, the locales transcribed the
names of our product, which is perfectly fine. At least as long as the analysis
above is correct. CCing the owners to keep them informed.

Comment 2

12 years ago
This is an ugly problem some locales in FFx and TBird
Flags: blocking1.8.0.3?

Updated

12 years ago
Flags: blocking1.8.0.4+
Flags: blocking1.8.0.3?
Flags: blocking1.8.0.3-

Comment 3

12 years ago
There's an interesting side effect from these locales translate the brand name "Firefox" and "Thunderbird". We insert the brand name in the outgoing user-agent header for e-mail. So instead of seeing Thunderbird 1.5.0.2 (Windows/20060308) in the user agent header for e-mail from these users, I instead see a group of non encoded illegal 8-bit characters in the mail header. 

Comment 4

12 years ago
I filed bug 334993 on the User-Agent issue.

Note that I'm pretty sure that nsIXULAppInfo one of the possible ways to
fix nsPostUpdateWin.js, or we can preprocess it.

Comment 5

12 years ago
Preprocess "it"? You can't preprocess nsPostUpdateWin with locale-specific information, that will break repackaging.

Comment 6

12 years ago
The point is that the app name part of the registry key must not be locale
specific. At least it is not in the installer nor the uninstaller.
It'd be good to have source references in both of these where they access registry
keys including the product name.

Comment 7

12 years ago
I'm almost positive the installer gets its information from installer.cfg

Comment 8

12 years ago
There are at least two ways to fix this: we could fix the installer to use the correct localized useragent string, or fix postupdate to know about the nonlocalized string that the installer knows about. I'm not certain which one is easier/better.
nsPostUpdateWin.js is all Darin -> reassigning from "nobody"
Assignee: nobody → darin
Summary: Tbird gu-IN and pa-IN updated Windows unistallers are broken → gu-IN and pa-IN uninstall broken after update (Windows, FF+Tbird)

Comment 10

12 years ago
There's also bug 339344, but I can reproduce that one without auto-update.
not sure an uninstall failure ever rises to the level of "blocker".
Severity: blocker → normal
Flags: blocking1.8.0.5+ → blocking1.8.0.5-

Comment 12

12 years ago
Darin, could we get this fixed for 2.0?
Flags: blocking-firefox2?

Comment 13

12 years ago
Axel: so, this bug exists in 2 as well?

Comment 14

12 years ago
Yes, this is an updater problem, IIRC, and not related to the installer.
The lxr link in the URL at least didn't change AFAICT on the 1.8 branch.
Not going to block on a problem involving bad translations of something that shouldn't be translated.
Flags: blocking-firefox2? → blocking-firefox2-

Comment 16

12 years ago
Can we just ask the localizers to NOT translate the brand name?  That will fix this problem too, right?

Why are people translating the brand names anyway?  I understand that some people will not be able to read "Firefox" and "Thunderbird" if it's not in their language, but do we have any policy on whether or not translating those words is ok?

mconner: If we are going to push for better l10n parity with en-US for 2.0, I would think we still need to think about what's best for this bug.  Granted, gu-IN and pa-IN are not P1 locales, but I think India is an important region to think about for the future, and we shouldn't just ignore issues with those users.

Comment 17

12 years ago
The indian locales don't translate the names, they transcribe it, IIRC, like the l10n trademarks policy says.
In addition, these changes are intended to be possible, it's just that the updater shouldn't pull the localized appname, but the appname from nsIXULAppInfo or what it's called. This is not a bug in the localizations, but a bug in the app exposed by the localizations.
Renominating for consideration of Axel's comments ("use nsIXULAppInfo")
Flags: blocking-firefox2- → blocking-firefox2?
Have people tested if this is present with the NSIS installer?
We're not sure that this is a problem with the new NSIS installer, and these aren't tier 1 locales, so we're not going to block on this.

cc'ing phik and cbeard to keep 'em in the loop.
Flags: blocking-firefox2? → blocking-firefox2-

Comment 21

12 years ago
Both pa-IN and gu-IN use English as installer language, due to font issues.

Thus, even if the installer would localize the product name (which it doesn't), it would be the English names.

Of course, we haven't done any updates post-NSIS, but this is, again, not an installer bug. If the installer would use the localized name for registry keys, that'd be a different bug, as we (silently?) agreed that having localized names in registry keys isn't helping anybody.

Comment 22

11 years ago
-> reassign to default owner
Assignee: darin.moz → nobody

Comment 23

11 years ago
For Gujarati (gu-IN), i have modified all brand names (Firefox/Thunderbird/Mozilla) to english in CVS (MOZILLA_1_8_BRANCH). Please let me know, if the build still fails.

Comment 24

11 years ago
Ankit, that check-in didn't have a patch, let alone an approved patch. The branch is frozen, please attach a patch corresponding to your check-in to a new bug and request approval1.8.1.5. Attaching it to this bug won't do.

Updated

11 years ago
Depends on: 384013
(Assignee)

Updated

10 years ago
Product: Firefox → Toolkit
This shouldn't be a problem in 1.8.1 and above... 1.8.0 is EOL. Can this be resolved -> wontfix or sumthin?

Updated

10 years ago
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.