I'm running nightly build so that's Deer Park. But when I get the update from the update channel and the update is applied it says "Firefox is updating". So perhaps the dialog isn't using the correct appname term?

This is hard coded in http://lxr.mozilla.org/mozilla/source/browser/locales/en-US/updater/updater.ini

shouldn't updater.ini be updated to that it doesn't contain a hardcoded product name?

If somebody wants to write the patch, sure... it's certainly not a priority.

*** Bug 334852 has been marked as a duplicate of this bug. ***

Something like this? # browser/locales/en-US/updater/updater.ini.in ; This file is in the UTF-8 encoding [Strings] Title=Software Update Info=@MOZ_APP_DISPLAYNAME@ is installing your updates and will start in a few mo ments ... # configure.in AC_OUTPUT(browser/locales/en-US/updater/updater.ini)

*** Bug 345596 has been marked as a duplicate of this bug. ***

(In reply to comment #5) > Something like this? > > # browser/locales/en-US/updater/updater.ini.in > ; This file is in the UTF-8 encoding > [Strings] > Title=Software Update > Info=@MOZ_APP_DISPLAYNAME@ is installing your updates and will start in a few > mo ments ... > > # configure.in > AC_OUTPUT(browser/locales/en-US/updater/updater.ini) I don't think that will actually work with different locales. You might need to change that to a %S and then set the displayname somewhere else that the updater code can get to it, then use sprintf to format the string. It's possible that there's an easier way to do it, though.

This fixes this bug for me on 1.9.0.x (the patch is against the trunk)... I only tested this on 1.9 since I have an l10n setup for for it and haven't set one up for hg yet.

Comment on attachment 349065 [details] [diff] [review] patch rev 1 Forgot to include changes for Linux and Mac

Comment on attachment 349065 [details] [diff] [review] patch rev 1 I forgot we have a brain dead parser for ini files for Linux and Mac so this should be fine

Since this only affects nightly builds and requires a string change this should be landed (along with equivalent changes for other apps) after 3.1

Axel, this patch will change the l10n updater.ini file. How would you like to handle this change? Is it already checked in compare-locales? I could add a check to the existing verification of the installer l10n files if you like.

This should be fine as is, we already handle .ini files in compare-locales, at least the python versions handle it fine. And the perl versions aren't called into anymore anyway.

Comment on attachment 351087 [details] [diff] [review] comm-central patch Ause, could you review the SunBird portion of this patch? Thanks

Comment on attachment 351087 [details] [diff] [review] comm-central patch Phil, could you review the Thunderbird and Seamonkey portions of this patch? Thanks

Comment on attachment 351087 [details] [diff] [review] comm-central patch Without incriminating myself about any times I may or may not have pretended to be able to do simple build config or installer reviews for SeaMonkey, let's have mcsmurf do the SM third of one, for the review trifecta.

Mmm, this needs to be ifdeffed, since comm-central "trunk" is currently building against 1.9.1 rather than mozilla-central. Sadly, I don't actually know ifdef *what*, though.

Phil, I can hold off for now if comm-central is going to move over soon or just change Info to InfoText and leave the hardcoded brandShortName. Are there plans to have comm-central build off of 1.9.1?

After asking Standard8 what I think, I think the best thing to do is to keep the Info string, add the InfoText string, and ifdef the Makefile.in lines, just as soon as someone figures out a convenient way to define MOZILLA_1_9_1_BRANCH in comm-central's configure.in if MOZILLA_VERSION starts with "1.9.1". Then once we branch comm-central, we can take out the Info string on the trunk (though we'll probably be string-frozen by then, and stuck with shipping the unused InfoText string in the 1.9.1 releases).

We now have comm-central building on 1.9.1 and we have MOZILLA_1_9_1_BRANCH. Although all I think needs to be done here is to put both Info and InfoText in the locale file and just add a comment saying something along the lines of: Info is only required for the MOZILLA_1_9_1_BRANCH Then once we get to branching, we can clean up.

iirc the ini parser used for Mac OS X and Linux by the updater is extremely simplistic in that it relies on the position of the string in updater.ini and then just uses the string after the = sign. So, it will take a bit more than that. :(

The patch in bug 399153 makes all platforms use readstrings so changes to the names for the strings (e.g. Title and Info) no longer requires changes to progressui_win.cpp to reflect these changes. This means that each app will be able to fix this bug in the same way as I will be fixing it for Firefox at any time they choose so I'm removing the dependency on bug 467878. I'll fix this on mozilla-central after bug 399153 lands.

With the changes made to progressui_win.cpp by the landing of bug 399153 the progressui_win.cpp changes are no longer needed to fix this.

Pushed to mozilla-central http://hg.mozilla.org/mozilla-central/rev/6128896b6f98

Comment on attachment 356140 [details] [diff] [review] patch - as checked in Bah, forgot this one

Comment on attachment 356140 [details] [diff] [review] patch - as checked in a191=beltzner

Pushed to mozilla-1.9.1 http://hg.mozilla.org/releases/mozilla-1.9.1/rev/a48dcceb93b8

verified FIXED on builds: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090413 Minefield/3.6a1pre ID:20090413031052 and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090413 Shiretoko/3.5b4pre ID:20090413031313

ack, here's the build ID for Shiretoko Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090413 Shiretoko/3.5b4pre ID:20090413031313