if you update from Thunderbird from 1.5 to 220.127.116.11, the gu-IN and pa-IN unistallers are broken. The straight installed versions of 1.5 and 18.104.22.168 uninstallers for those locales work fine. -install 1.5 -update to 22.214.171.124 tested results: The add/remove item for Thunderbird 126.96.36.199 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 188.8.131.52 and unistalling works endign with bringing up the new survey dialog. Didn't know where else to file this, Axel suggested here.
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 184.108.40.206: 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.
This is an ugly problem some locales in FFx and TBird
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 220.127.116.11 (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.
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.
Preprocess "it"? You can't preprocess nsPostUpdateWin with locale-specific information, that will break repackaging.
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.
I'm almost positive the installer gets its information from installer.cfg
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)
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: blocking18.104.22.168+ → blocking22.214.171.124-
Darin, could we get this fixed for 2.0?
Axel: so, this bug exists in 2 as well?
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-
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.
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-
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.
-> reassign to default owner
Assignee: darin.moz → nobody
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.
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 approval126.96.36.199. Attaching it to this bug won't do.
This shouldn't be a problem in 1.8.1 and above... 1.8.0 is EOL. Can this be resolved -> wontfix or sumthin?
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.