This bug is to remove the menu item "For Internet Explorer Users" from the Help menu. The rationale is that this help page provides very little additional information beyond what is directly available from Firefox > Help. The IE help focuses specifically on importing bookmarks (which the user may or may not be interested in), and on very subtle terminology differences. This information isn't very high value, the import wizard was already presented to the user as part of their installation process, and in many cases the user might not even remember the IE terminology well enough to detect that our terminology is slightly different. We should still of course have all of this information available through Firefox > Help, this bug simply asserts that we do not need to provide a dedicated menu item.

I can take this if the decision has been finalized to remove this.

Yes, I don't think this is of much use anymore. I'm sure it was useful back in the day.

The UX team is very eager to get this bug landed over the next few days in order to make Beta 11. If anyone can get a patch for this bug posted soon, we will push hard for reviews and approval (even though this isn't blocking). You can view all of the related bugs to clean up the traditional menu bar here: http://areweprettyyet.com/4/traditionalMenu/

Comment on attachment 506658 [details] [diff] [review] Removes the IE stuff from Help Menu Gavin said we should better evaluate if we want this kind of .dtd string noise (even if it's just removal) at this late stage. Re-setting the approval request for evaluation.

(In reply to comment #5) > Comment on attachment 506658 [details] [diff] [review] > --> https://bugzilla.mozilla.org/attachment.cgi?id=506658 > Removes the IE stuff from Help Menu > > Gavin said we should better evaluate if we want this kind of .dtd string noise > (even if it's just removal) at this late stage. > Re-setting the approval request for evaluation. With my localizer hat on, no, we don't, at all! This just makes our localizers do needless work, and believe me, they have a lot more to help with the release of Firefox 4.

Wait — unused strings cause extra work? Is our localization system really that broken? (Honest question, I am used to po-file based systems, where it's not an issue at all) Or do you mean that they'll be translating strings that won't be ultimately used in the product, so therefore this is "extra work"? If that's the case, the improved menus should take precedence, especially since these are strings that have been in the product essentially forever, and are likely to already be translated in existing languages. Again, I don't mean to be flippant, I just don't know exactly how our translation system works. Feel free to school me on it if I'm wrong. :)

I don't see why this patch is any different than the patch for #607234 or #572695, both of which changed .dtd strings and they've both landed and are verified fixed.

(In reply to comment #7) > Wait — unused strings cause extra work? Is our localization system really that > broken? (Honest question, I am used to po-file based systems, where it's not an > issue at all) > > Or do you mean that they'll be translating strings that won't be ultimately > used in the product, so therefore this is "extra work"? If that's the case, the > improved menus should take precedence, especially since these are strings that > have been in the product essentially forever, and are likely to already be > translated in existing languages. > > Again, I don't mean to be flippant, I just don't know exactly how our > translation system works. Feel free to school me on it if I'm wrong. :) I mean they will get obsolete string warnings from compare_locales, which may urge them to delete the strings in their locales to shut that warning up! I didn't mean to imply that there is any new translation work that's going to go to waste...

(In reply to comment #9) > I mean they will get obsolete string warnings from compare_locales, which may > urge them to delete the strings in their locales to shut that warning up! I > didn't mean to imply that there is any new translation work that's going to go > to waste... I see. Not optimal, of course — but I wouldn't say it's risky or causes more work for people. In that case, I propose that we move forward with this, similar to bug 607234 and bug 572695.

I'm not proposing that we shouldn't remove the menu item, but I still know that removing the strings is going to cause unneeded l10n churn. CCing Pike and Beltzner for their comments. (Hint: remember, I'm also a localizer myself ;-) )

(In reply to comment #11) > I'm not proposing that we shouldn't remove the menu item, but I still know that > removing the strings is going to cause unneeded l10n churn. CCing Pike and > Beltzner for their comments. Ah, then I misunderstood. Yes, it's fine to have them in the product, I just care about the menu item. If there's an unused translation, that's fine. So, we agree!

Keeping un-used strings is a three-bladed sword. (oh, hong kong flic to be seen) - removing them causes noise to existing localizers. likely little to those on tools, more for those on plain editors - not removing them comes with two: -- we don't have a good track record of actually fixing "remove this string" follow ups -- localizers starting new localizations based on 4.0 waste some cycles. In this particular case, given that we have bigger fish coming in still, I'd rather land the removal now. Totally unrelated question, is removing a menu item and thus a hook for add-on overlays add-on-compat-breaking? Goes for all of the menu shuffling. Yeah, this one is platform specific, but still.

Comment on attachment 506658 [details] [diff] [review] Removes the IE stuff from Help Menu Yes, there is a risk of breaking addon menu item positioning. That isn't disastrous, since it just means the overlayed menu item will be positioned incorrectly. In this specific case, it's unlikely that addons will have used this menu item as an anchor (due to its position, and platform-specificness).

Unbitrotted, I'm going to land it with other stuff.

Verified fixed with Mozilla/5.0 (Windows NT 5.1; rv:2.0b12pre) Gecko/20110208 Firefox/4.0b12pre The Litmus test has been updated