Closed Bug 324189 Opened 15 years ago Closed 2 years ago

inspector shouldn't download languages it doesn't need

Categories

(Other Applications :: DOM Inspector, defect, P3)

All
Windows XP
defect

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: brianr, Unassigned)

References

Details

(Whiteboard: [blocked on extension locale work])

refactor inspector using extension locale packs (not yet implemented) so that we only include the matching language for each locale of the installer.  This should shrink the size of the download and will allow us to put in the spelling dictionary.
Flags: blocking-firefox2?
Depends on: 285848
A couple of thoughts... possibly use extension dependencies (bug 298497) to help with associating the locale to the extension - especially in regards to ui. We can distinguish between locale dependencies from extension dependencies since a locale has an em:type of 8. We would also need to fix bug 310843 since that prevents reading the em:type in a install.rdf unless it is specified as an integer data type in the rdf.
Priority: -- → P3
Whiteboard: [blocked on extension locale work]
We're going to save even more space by not downloading inspector in the installer, unless selected as an optional component.
Flags: blocking-firefox2? → blocking-firefox2+
What you are asking for is essentially a third installer package.
1) full offline installer
2) installer with ability to download optional components
3) stub installer that downloads everything

I have signed up for #1 and will attempt to accomplish #3 as long as taking that on doesn't adversely affect the other items I have for 2.0... #2 doesn't have an owner for 2.0 and my plate is already full.
I think for our purposes, #2 is preferred to #1, based on the thread in dev-apps-firefox.  Is #2 that hard once the framework is in place to do #3 and #1?
Target Milestone: Firefox 2 → Firefox 2 beta1
What it will take to accomplish numbers 2 and 3 above and beyond adding the download functionality, ui specifically for this, QA of these new install methods, fixing of bugs associated with all three of these additional methods is to also create the additional build processes etc. for them. As is I am taking the existing installer and porting it over to NSIS - sounds simple but it isn't - and adding two additional ones for 2.0 especially when I need to start on this bug, Extension Locales, Extension Update Notification, and Branding and Locale installer customization plus several Extension Manager bugs and additional work on Extension Blacklisting and Extension Dependencies, etc. is just asking for trouble.
So we have two distinct directions here, right?
Bringing back l10n modularity to inspector by creating separate locale packs, and
optionally shipping inspector (and it's locale pack).

I'm tempted to say that we could try to get l10n of inspector modularized, if
we could create multiple-item add-ons by the build system, because we do want the 
installer l10n pack to have dependencies on the inspector version, I guess. Not 
sure how much work in build logic that is.

I guess that should be independent of wether we ship inspector at all or not.
Based on the fact that we are pulling DOMi minusing
Flags: blocking-firefox2+ → blocking-firefox2-
Assignee: benjamin → nobody
Product: Firefox → Toolkit
Target Milestone: mozilla1.8.1beta1 → ---
Given that DOMi is now just an add-on I suspect this isn't going to happen, but it is a DOMi bug anyway...
Component: Add-ons Manager → DOM Inspector
Flags: blocking-firefox2-
Product: Toolkit → Other Applications
QA Contact: extension.manager → dom-inspector
Unless language packs and extension dependencies become a reality, I do not see this happening.
I have implemented locale packs with extension dependencies for ChatZilla and venkman, I probably can look into doing this for DOMi as well some time, but I don't know when I come around to do it. Both Add-Ons manager window and AMO are thinking about improvements to supports those langpacks better, from what I hear coming out of Summit talks.
Bulk close. This component is no longer supported or maintained.

https://bugzilla.mozilla.org/show_bug.cgi?id=1499023
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INCOMPLETE
Bulk close. This component is no longer supported or maintained.

https://bugzilla.mozilla.org/show_bug.cgi?id=1499023
You need to log in before you can comment on or make changes to this bug.