We are planning on seprating the language UI from the content in Customization Packs (aka Language Packs). To do this, we will need to provide the user with a means to edit their language UI and Content preference. I propose we add the following tabs to Preferences | Appearance: Language Regional Content Nominating for nsbeta1. ------- Additional Comments From Jaime Rodriguez, Jr. 2001-01-02 17:50 ------- Adding nsbeta1 and intl keywords. Adding Msanz and Blee to cc: list. P.S. - Under Preferences | Navigator, exist the tab "Languages". Hence, we need a good name for language UI. Taking suggestions . . .

------- Additional Comments From timeless@mac.com 2001-01-03 00:05 ------- I did this once [before things split]. I'll attach the current work and then we can discuss how to make it more correct. ------- Additional Comments From timeless@mac.com 2001-01-03 00:07 ------- Created an attachment (id=21647) preftran.zip ------- Additional Comments From Matthew Thomas (mpt) 2001-01-03 22:56 ------- I suggest this bug be wontfixed and bug 64147 be fixed instead. If I need to change my UI language, I probably won't be able to read the preferences categories, so finding the correct one would be a nightmare. Finding it in the profile manager would be much easier. ------- Additional Comments From timeless@mac.com 2001-01-04 12:03 ------- I suggest we ignore mpt and use this as an overlay style. The panel can be available in both windows. I think most people are able to read enough english to get to the preferences dialog, and explaining how to get to profile manager is hard. Personally I test stuff and I hate restarting applications. I need to be able to switch languages to see how things look. But I shouldn't need to restart mozilla to do it. Someone working on a translation is likely to do the same. ------- Additional Comments From Viswanath Ramachandran 2001-01-12 11:57 ------- nav triage: yes this is critical. upgrading to P1.

Creating new bug to remove Netscape Confidential information. Formerly bugzilla 64144.

over to prefs.

nav triage team: Marking nsbeta1+

timeless: hows this one going? can XPApps people help in any way? what is the target milestone when you would like to have a patch ready for this? thanks, Vishy

Can somebody tell me how this is being used, ie. how often do users switch this setting, when do they switch and what is the trigger/motivation.

German - Sure thing . . . Why don't we meet for a few minutes next week to discuss the feature with Todd, and Tao.

after your discussion, please inline a summary, thanks.

Met with German on Wednesday, 02.21.01. We reviewed the feature and its future versioning. Addtionally, we provided him the original Language Pack doucment for his use. Next steps, will be for German to propose new UI specification to address the separation of Language and Content. German - Can you provide Timeless with an Update.

I have better understanding now what the separation of UI Language and Regional content packs mean. I am now of the belief that the change of the UI Language is probably much less frequent than that of regional packs, meaning the UI language selection should prob be a pref which is then peristed in the profile. Regional Content Packs however are envisioned to be changed frequently, thus I would assume they are similar to themes, meaning we should add them to the View menu similar to "Apply Theme". Adding them to prefs is optional.

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

German writes: "I have better understanding now what the separation of UI Language and Regional content packs mean. I am now of the belief that the change of the UI Language is probably much less frequent than that of regional packs, meaning the UI language selection should prob be a pref which is then peristed in the profile." Agreed. I would go so far as to say that there should be *no* UI for this at all in seamonkey, at least by default(*). If, after the novelty wears off, the average user changes skins maybe (at most) four times per year, how often is language pack going to be changed? I'm not concerned with international users with special needs here, I'm talking about people using the product in a single configuration. "Regional Content Packs however are envisioned to be changed frequently, thus I would assume they are similar to themes, meaning we should add them to the View menu similar to "Apply Theme". Adding them to prefs is optional." I would tend to discourage adding any such menu items to an already overcrowded menu as these options are only likely to be meaningful to the tiny minority of users who have multiple region data installed. (*) (*) - the only way this UI would make sense is if it was only apparent when the browser was run in a special mode - i.e. more than one pack present. This is likely an edge case.

Changed QA contact to andreasb@netscape.com.

Changing QA contact to jonrubin@netscape.com.

resassigning to nhotta.

Reassign to vishy.

Ben - I don't believe these are menu items. These are changes to the Preferences | Appearance. Currently, there are only 3 items under Appearance. Pls see the attached proposal.

nav triage team: navigator does not have time for this, reassigning to Jaime.

Vishy - In assigning to me, are you requesting help from i18n (i.e. If we accpet and create a patch, will your team accept the change and review)?

Assuming that this proposal has passed the Mozilla UI design review stage: not sure if it has done so?

Vishy/Asa - Pls see timeless comments . . . "I suggest we ignore mpt and use this as an overlay style. The panel can be available in both windows. I think most people are able to read enough english to get to the preferences dialog, and explaining how to get to profile manager is hard." Most international and expat users will now how enough english, or other language, to navigate the Prefrences window to change the Language UI and Content of the browser. Addtionally, this change would allow people to change Regional Content location, as well as language. If a user is allowed to change the setting for prefered Web Language (Edit | Preferences | Navigator | Languages), shouldn't they have the ability to change Language interface they are using?

Vishy - Suggest we accept German's proposal, and accpet the fix for this one, as it is marked nsbeta1+ and M0.9.1; and address the Menu items in View menu as a seperate issue.

RFE for the future: I would like the .rdf to include a description of the content. E.g., chrome:description="xxx" and the pref dialog would have a way to display the desciption -- possibly a "get info" button. So in the example from: http://www.mozilla.org/projects/ui/communicator/framework/langcontentui/ If I select "Bay Area Regional" and click on the "Get Info" button, it might display: Activities and entertainment guides for the San Francisco Bay Area. Or if I select "Sports" and click on the "Get Info" button, it might display: News and gossip about WWF, Monster Trucks and Mud Wrestling.

reassigning back to ben. changing milestone to M0.9.2 because we need it then. changing to nsbeta1-. this one does not meet beta stopper guidelines.

How can we `accept German's proposal', when (1) it doesn't describe what this feature *is*, (2) it doesn't describe who would use the feature, (3) it doesn't explain what they would use it for, (4) it doesn't explain why this feature should be included in the Mozilla trunk when (as I suspect is the case) mozilla.org will not be in the business of providing the `content' to make it work, and (5) it doesn't even specify what the UI would look like? The proposal consists mostly of broken-image icons, and I'm sorry to say that broken-image icons aren't really very informative.

mpt: I just double checked and can see all images in the posted UI document OK. I'd be happy to email it to you, if you're having troubles.

per mpt's comments: adding related UI bugs to the dependency tree to provide better way of cross- referencing the somewhat disparate sources of information. Here are pointers to Tao's localization project, which will hopefully provide a path of enlightenment on the topic of language and regional content bundling: Regional Content Bundling http://www.mozilla.org/projects/l10n/mlp_regional.html Please note that Mozilla has divided up the original language pack from en- US.jar into en.jar (language pack), US.jar (regional content pack) and en- XXX.jar (platform-related en-linux, en-win, ... ). Click below for the gory details: L10n Packaging http://www.mozilla.org/projects/l10n/mlp_what2.html#chrome_files http://www.mozilla.org/projects/l10n/mlp_packaging.html German's UI (image references are now functional): http://www.mozilla.org/projects/ui/communicator/framework/langcontentui/

Vishy - Looks like we have a patch. Can you help us, with the r and sr?

We have no patch for this, bug 65253 has a patch which needs 'r' and 'sr'.

This is required for RTM. Marking as such.

I'll look at this tomorrow morning. (-evening of 06/04/2001)

Comments, based on the screenshots: "Choose your preferred language for the Mozilla program." 1) Don't use the word "program" 2) This text does not really adequately explain the affect of this change. Something that mentions that it controls all dialog text, menus etc (of course, worded better) should be present. This could be a potentially catastrophic change for the majority users, so we should make sure that it's obvious what it does. This could perhaps be facilitated with a preview area perhaps with a sample of a dialog showing text in the selected language. 3) The "Show Tooltips" option should be above the language selection, and there should be a separator (<separator/>) between the show tooltips option and the language option. "Content Packs" preference panel: 1) I am not convinced there is a need for this UI in Mozilla. The subsystem of allowing vendor customization of defaults is potentially useful in Mozilla as vendor customization is something that many distributors may wish to do, however providing a UI for this feature seems rather odd. I would suggest either a) providing an explanation of how this UI is beneficial to Mozilla and its customers, or b) placing this UI in Netscape's commercial tree. As for the UI itself... 2) "Throbber" is not a term that most end users will be aware of the meaning of. 3) 'default homepage' - 'homepage' isn't a word. Other parts of the browser refer to this concept as "Home Page". What does 'default' mean? I know what it means, will a user? Does it mean that by switching "content packs" that their current 'homepage' is lost? 4) 'the sidebar' - other parts of the application refer to the sidebar consistently as "My Sidebar". 5) 'Warning: changing content requires you to restart mozilla.' i) This is not really a 'warning,' it's a note. ii) 'content' or 'content pack'. Use consistent terminology. iii) 'mozilla' - Uncapitalized suggests that this is not being located from brand.dtd. Use &brandShortName; so that Netscape gets the correct and capitalized strin. Since the description text suggests no means is provided for dynamic content pack switching, why not do away with the "Apply" button and remember the selected item? One of the big UI issues with the themes panel was with people selecting a new theme and clicking OK expecting it to take.

Another point I forgot to mention earlier: The download page, if it is a webpage, should just be loaded in a new browser window rather than creating a separate window for this purpose. Creating a custom window appears to have its own problems (as demonstrated by the screenshot) - inappropriate sizing - lack of regular browsing features such as context menus etc.

Code: (aPrefString == "mailnews.view_default_charset") || + (aPrefString == "general.useragent.locale") || (aPrefString == "mailnews.send_default_charset")) { Can we please remove this section of code, and add another pref type case in the switch statement here? I don't want to see this list growing. The prefwindow code is supposed to be preference-independent and just adding to the pile when the correct solution is simple doesn't help.

Cc to l10n for the UI change.

nav+pdt triage: -> juraj

Jaime: could you please provide additional input for the provisional wording used in patch #1? Ben: thank you very much your careful review, I'm working on the resolution and will post a new patch shortly. I tried to adhere to German's UI spec as much as I could. Although I might have missed a thing here or there, I do believe that the points you are raising are important and valid. I'll be sending out an email to all the involved, with the intention of expedite the consensus building process and avoid multiple rework. I'll try to catch you on IRC, to discuss things further, if necessary.

Ben: blake and others are forcing some other poor soul (gerv) to replace My Sidebar w/ Sidebar or the sidebar (as needed).

timeless: thanks for the reminder - I believe I've read the bug report on it a while back and assumed the change from "My Sidebar" to "Sidebar" has either been completed or is imminent... I also believe Netscape might stick with "My Sidebar" in their commercial build. Ben: I'm attaching a new proposal for the download popup. Please understand that I personally dislike this part of the new UI the most. The download list should be an RDF-based list or something similar. Personally, I'd not recommend opening a opening a full browser window. I tried that on Friday; if you attempt to select "Preferences" in your new browser instance, you original pref dialog will be reset... I know this is only a remote possibility, but it still needs to be considered. The preferred language UI preview is a cool idea and I saw some effort in that direction in timeless' attachment 21647. I'd recommend filing a new bug on that, since all the language packs would need to include a partial screenshot of their menu bar or some dialog. Logistics will be the limiting factor here, especially with all the Mozilla contributors. Similarly, I fully realize the coding mess around the localizable string preferences and agree that it would be fairly easy to address. And again, I'd recommend a new bug. I have been advised by my manager (Frank Tang) to send that over to your group first and discuss the responsibilities later. As to the relevance of the "Content Packs" pref panel for Mozilla: both the l10n and i18n groups at Netscape feel it is relevant and would be happy to rally some external contributors behind this claim. And again, I have to stress that this is not my decision to make and that there has been fair amount of discussion on that topic. Please let me know, how you feel about these comments and whether the proposed approach is acceptable.

This comment from Ben: > I'm not concerned with international users > with special needs here, I'm talking about people using the product in a > single configuration. Doesn't make a lot of sense. We have to be concerned about all users. There is a preference panel that sets whether you want mail to come up by default and I have NEVER used it. Does that mean it shouldn't be there? If people are worried about there being too many preferences panels, it's way too late for that :) Seriously, if we need preference panels for things, we should add them. At least we have made the UI actually usable for lots of panels unlike IE and other applications (Opera) We (IBM) definitely like the UI content switching in Mozilla - not based on the profile manager. This is very useful. There are a number of countries where people use applications in multiple languages and need this. In Egypt, English, Arabic, and French are used, and it is useful to switch the UI between them. In Switzerland, German, French, and Italian are used and it is useful to switch between them. What about a browser at the Olympics? The UI needs to be available in Japanese, English, French, and the host country. Or how about a browser at an internet cafe as some have pointed out? This function is not just useful for testing, it is useful for people and for applications. Our goal with Mozilla should be to create a best of breed browser for the whole planet, not just English speaking countries. And we should try NOT to encourage Netscape (or any compant) to do stuff on their own and ship it. The only stuff any company should have to do above and beyond Mozilla is branding and proprietary stuff. This is what Mozilla is about. If someone has a good idea that benefits Mozilla, why wouldn't we take it?

laughing: > There is a preference panel that sets whether you want mail to come up by default and I have NEVER used it. > Does that mean it shouldn't be there? YES!!! PLEASE KILL IT!!! rotfl. oh but the rest of the comment is pretty accurate. -- pref-appearance.xul imo that's too much js for a xul file, please use the associated js file or create one. if there is a precedent for indentation (or a modeline) pleae follow it, your patches show that you are either internally inconsistent or inconsistent w/ local code. -- i realize it's a -uwb so that might not really be the case [but for internally inconsistent you're clearly wrong]...

Juraj - "I'm attaching a new proposal for the download popup. Please understand that I personally dislike this part of the new UI the most. The download list should be an RDF-based list or something similar." Agreed. Although I bet this requires more from the Netscape.com folks that they'd rather not provide ;) "Personally, I'd not recommend opening a opening a full browser window. I tried that on Friday; if you attempt to select "Preferences" in your new browser instance, you original pref dialog will be reset... I know this is only a remote possibility, but it still needs to be considered." This is probably a little more work than you were planning on doing, but it's a fairly easy fix, and you'll be fixing this horrid bug for everyone: Go into xpfe/communicator/resources/content/utilityOverlay.js grep for 'function goPreferences' (~ line 130) replace the line that calls openDialog with: const kWindowMediatorContractID = "@mozilla.org/rdf/datasource;1?name=window-mediator"; const kWindowMediatorIID = Components.interfaces.nsIWindowMediator; const kWindowMediator = Components.classes[kWindowMediatorContractID].getService(kWindowMediatorIID); var lastPrefWindow = kWindowMediator.getMostRecentWindow("mozilla:preferences"); if (lastPrefWindow) lastPrefWindow.focus(); else // put the old openDialog call here The problem you were seeing with opening prefs resetting the pref session has been happening for some time - the pref window is not application modal, only window-modal, and so if you have two browser windows up (likely) or even a browser and a mail window up (also likely) then invoking the pref window twice will reset the session. The code above checks for an existing window and focuses it, which should bring it, and its parent window to the front. The primary reason I recommended loading a web page in a browser window is that a) It's important to show progress for network activities (and the browser has a set of mechanisms that show progress for free), and b) Some people like to know what remote sites they're being taken to (urlbar/status bar provides that info) "The preferred language UI preview is a cool idea and I saw some effort in that direction in timeless' attachment 21647. I'd recommend filing a new bug on that, since all the language packs would need to include a partial screenshot of their menu bar or some dialog. Logistics will be the limiting factor here, especially with all the Mozilla contributors." Sure. "Similarly, I fully realize the coding mess around the localizable string preferences and agree that it would be fairly easy to address. And again, I'd recommend a new bug. I have been advised by my manager (Frank Tang) to send that over to your group first and discuss the responsibilities later." Nothing really needs discussing. Here's the modified code: // ... case "localizable": return pref.getLocalizedUnicharPref(aPrefString); case "color": case "string": default: // ... This would require going into each of the panels and replacing the preftype attribute value with "localizable". Not too difficult. Maybe you could persuade Frank to do it ;-)

Michael - "Doesn't make a lot of sense. We have to be concerned about all users." Have you heard the saying "chase two rabbits and you'll lose both of them?" I am not denying that there are users with special needs, such as switching content packs, etc. What I am doing is questioning the overlap of those users' needs with the needs of the majority. That does not mean I'm saying "screw you" to those users, I'm just trying to encourage the people developing for those users to develop their features in a way such that there is minimal interference for everybody else. If there is a special need associated with a certain demographic, then produce a build for that demographic. "There is a preference panel that sets whether you want mail to come up by default and I have NEVER used it. Does that mean it shouldn't be there?" That issue is orthogonal to this. I'm concerned with any UI that shouldn't be part of our default distribution. If you have a problem with this startup UI, file a bug. "If people are worried about there being too many preferences panels, it's way too late for that :) Seriously, if we need preference panels for things, we should add them. At least we have made the UI actually usable for lots of panels unlike IE and other applications (Opera)" Sorry, that's kangaroo logic, and will only lead to spiralling complexity and bloat. I'm concerned with providing each set of users the UI that is relevant to them. Anything more than that is added complexity that only results in user confusion, added support costs and other issues down the road. "There are a number of countries where people use applications in multiple languages and need this. In Egypt, English, Arabic, and French are used, and it is useful to switch the UI between them." Are you talking about language now or content packs? I can see a potential use for UI language switching. I believe that's probably best kept at the profile manager level, as a user who accidentally switches language for their profile may not know how to get back to their original language, putting them into a broken state similar to switching to a malicious skin. This is a trap that few software packages allows you to fall into. However, if there are technical reasons we can't do this, then I suppose a preferences UI with sufficient big flashing warning signs (or preview) is appropriate. As for Content packs - I don't know a great deal about how they work as the explanation provided isn't terribly detailed. Does this mean that if I switch packs, all my bookmarks I collected in pack A are gone? Why do I need to switch locale packs anyway to adjust bookmarks, isn't that what our bookmarking system, complete with the ability to organize things into folders, is for? "What about a browser at the Olympics? The UI needs to be available in Japanese, English, French, and the host country. Or how about a browser at an internet cafe as some have pointed out?" So create a custom kiosk build for those people. Or not even a build, a set of optional add-ons. I think that if this functionality is to be included in Mozilla (and you've made some valid points for its inclusion) then it should be included as an extension, not built by default. It's something that distributors can include in whichever install paths they choose. IBM, for instance could distribute installers whose default install included this add-on. "Our goal with Mozilla should be to create a best of breed browser for the whole planet, not just English speaking countries." I agree, but we must remember to create UI in an intelligent fashion so that any additional complexity required by users with different requirements do not infringe on the space of another group.

OK, so given that Mozilla is a "developer" release, what makes more sense? 1. Create all the things that people need and allow companies that reship Mozilla to remove the things they don't want? 2. Create some of the things that people need and make companies add the things that they want on top of Mozilla in their own trees and implementation. I always thought Mozilla was #1. Be as many things to as many people as possible and then let people remove and repackage what they don't want. Mozilla should be creating ALL the technologies that people want. It is a developer release. By the way, this would all be moot if someone would just come up with a good architecture for preferences overlays....

Ben: "Are you talking about language now or content packs? I can see a potential use for UI language switching. I believe that's probably best kept at the profile manager level, as a user who accidentally switches language for their profile may not know how to get back to their original language, putting them into a broken state similar to switching to a malicious skin. This is a trap that few software packages allows you to fall into. " I think you should be able to change (most of the) prefs you set at profile creation also afterwards. Many people install Mozilla's english builds, creating a default profile, installing a language pack afterwards and switching to this language then. Second, if you're migrating a profile, you can get language settings you don't want etc. That's two reasons why I vote for having a pref panel for language and content switching. We should get this out of the "View" menu though, one place to change it is enough, and it's less disturbing in prefs IMO (different bug though).

Ben: >As for Content packs - I don't know a great deal about how they work as the >explanation provided isn't terribly detailed. Please refer to http://www.mozilla.org/projects/l10n/mlp_regional.html#regional > Does this mean that if I >switch packs, all my bookmarks I collected in pack A are gone? No, bookmarks and other profile-bound resources are not switchable once the profile is created. > Why do I need >to switch locale packs anyway to adjust bookmarks, isn't that what our >bookmarking system, complete with the ability to organize things into folders, >is for? "Regional pack" switching affects the locality of the default bookmarks which is copied from "[install-dir]/defaults/profile/[region-code]/bookmarks.html" into user profile directory. Once it is created; it's NOT switchable since it might contain user's customization (addition/edit/deletion) which we don't want to tamper with. "Regional switching" do affect the taskbar, Search menu, Home Page URL, etc. Feel free to let me know if more details is needed.

Michael - "1. Create all the things that people need and allow companies that reship Mozilla to remove the things they don't want? 2. Create some of the things that people need and make companies add the things that they want on top of Mozilla in their own trees and implementation." I figured this was a Netscape thing. Looks like I was wrong. OK - then I believe if this is to be done it should be done as an extension. There are distributors that may not want this feature, and (as you say) should be able to remove it. The standard method we have for doing that is by creating extensions which one can selectively build. What deficiencies have you found in the dynamic overlaying mechanism?

Tao - thanks for the comments. They've cleared a lot of things up. My revised comments are: - all the wording points I made in my original comments - text explaining the severity of a language change. - move the language selector under show tooltips - creation of an extension for this code, so that it can dynamically overlay into Navigator For Mozilla, the default build policy for this extension should be "off"

>- creation of an extension for this code, so that it can dynamically overlay >into Navigator > For Mozilla, the default build policy for this extension should be "off" Disagree. Ben- Why you are keep arguing that we don't need this in mozilla? Do you care about your customer/partner ?

Frank, if you read my recent statements you can see that I do think this has a place in Mozilla. As an extension. And I do care about Mozilla and Netscape's customers. I happen to think that the vast majority of them have no interest in this feature, and that their experience would be simplified by not offering this functionality to them. I don't make these decisions for Netscape however, so an extension allows them (and any other interested Mozilla distributors) to selectively build this functionality. Don't think I'm picking on this feature in particular. This is just one of many features that should receive this treatment.

I agree with Ben. It's possible that Netscape will be able to maintain multiple working content packs for their distribution (though unlikely, judging by their past efforts at similar features); but the majority of Mozilla distributors would not have the resources to do this, even if they shared Netscape's opinion that content packs were useful in the first place. So content packs should be an extension, and should be turned off in mozilla.org builds -- because the effort required by Netscape to turn the feature on would be less than the effort required by most other distributors to turn the feature off. So what are content packs for? I'm reading from Tao's page here. Built-in URLs? Shouldn't exist, because they are subject to linkrot. Taskbar? Doesn't exist. Search menu? Shouldn't exist, because it's bad UI (it only has four items, three of which obviously belong somewhere else). Internet Search engines default? Should be set in a single URL field in your prefs, inherited from the `Search Page' setting in the Internet control panel. Bookmarks? According to Tao's comment, if the user has ever touched their bookmarks, these wouldn't be changed anyway. Sidebar `channels'? The Bookmarks and History panels should be localized as part of the chrome, Search can sniff your settings from the Language prefs, and other panels are more discoverable if they're downloaded individually than if they're downloaded en masse as some mysterious `pack'. So, in sum, `content packs' allow you to change various things which don't exist, which shouldn't exist, or which are better changed by another method. >... > Or how about a browser at an internet cafe as some have pointed out? At our Internet cafe, the tourists and international students who have Japanese, Chinese, Korean, Thai, French, German, Swiss German, Hebrew, and Russian as their first languages come close to outnumbering the customers who have English as their first language. Not *once* have I ever had a request from a customer to change the language of the UI -- and as for `content packs', if I even tried to explain to customers what they were, I'd be laughed off. Generally Internet Explorer keeps out of their face, and `content' is what appears on Web pages rather than in the chrome. And that's as it should be. It's a Web browser. It's not a portal, or an OS, or a shopping mall. It's a Web browser.

ben- >As an extension. Disagree. There are no reason this should be an extension all other prefs using such extension scheme. Do you have such extension Netscape tell you that we need this feature on by default. IBM tell you that we need this feature on by default. several other individual and companies tell you that we need this feature on by default. Can you tell me why you still insist that this should not be there by default? Is there a bug filed to create such "extension" scheme in pref window ? Do you want me to file such bug, assign to you and mark it as a blocker for this bug ? Do you have time to finish this in one week so you can unblock this bug for moz0.9.2? >Don't think I'm picking on this feature in particular. This is just one of >many features that should receive this treatment. No, I am certain that you are not. However, I don't see other bug in your moz0.9.2 list "receive this treatment" (change to an extension scheme and turn OFF by default.) if you do think other pref absoluete should also be as an extension as well, why they are not filed and in your moz0.9.2 bug list? >I happen to think that the vast majority of them have no interest in this >feature, and that their experience would be simplified by not offering this >functionality to them. Is this your "personal feeling" ? or is this based on marketing study? if no body need this type of functionality, then could you explain to me why yahoo.com spend money on http://local.yahoo.com/ to offer regiaionl information? (content pack switching is basically the client side equivlent here). Why a lot o users use http://digitalcity.com which provide the server side solution to the regional switching ? mpt- >At our Internet cafe ... Not *once* have I ever had a request from >a customer to change the language of the UI -- and as for `content packs', if I >even tried to explain to customers what they were 10 years ago, if you work at that same cafe, no one will ask you if you have interent connection or not, simply because it does not exist. 10 years from now, if we make this feature successful, then they will ask you. >Generally Internet Explorer keeps out of their face, no wonder your customer never request this, they are using another product which do now have this feature.

This content pack siwthing idea is nothing new except it switch in the client site. many popular website offer such content switching by using cookie already. and millions of users already use them in their daily life. We simply move this swithcing closer to the user side in the client.

Ben, see also comments from 2001-05-17 in bug 65241. > Is this your "personal feeling" ? or is this based on marketing study? Frank, you're proposing adding this feature to Mozilla, so the burden of proof is on you to convince the module owner that it would be useful in default builds, not for the module owner to convince you that it wouldn't be. If you have studies (preferably usability studies, rather than marketing studies) showing that it would be useful, please attach them to this bug. Even without such studies, it's clear that moving content personalization from the server to the client would harm usability in several ways. * It would require that users carry around a floppy (or a laptop) containing their Mozilla profile folder, instead of just entering their user name and password to log in to their personalized site from any computer. * It would make personalized URLs less reliable than those on a Web site, because the URLs could not be corrected remotely by the Web site maintainer while the user was doing something else. * It would restrict users to using only those browsers close enough in the Mozilla family tree for their profile data to work with all of them. They couldn't use any non-Mozilla browser. > 10 years from now, if we make this feature successful, then they will ask > you. You mean, like Netcaster?

HEY. Leave Netcaster out of this!

"Netscape tell you that we need this feature on by default. IBM tell you that we need this feature on by default. several other individual and companies tell you that we need this feature on by default. Can you tell me why you still insist that this should not be there by default?" Yes, because I think it's unnecessary for most users. After speaking with a variety of users I have reached that conclusion. I am not preventing Netscape from shipping with this, nor am I preventing distributors of Mozilla from shipping with this. I've proposed the idea of an extension to staff@mozilla.org, Mitchell thought it sounded reasonable and I have not thus far received any disagreement from them. "Is there a bug filed to create such "extension" scheme in pref window ? Do you want me to file such bug, assign to you and mark it as a blocker for this bug ? Do you have time to finish this in one week so you can unblock this bug for moz0.9.2?" No such "scheme" is necessary, the technology of adding panels using dynamic overlays already exists. Look at what Mail/News does, what the Document Inspector does etc. "No, I am certain that you are not. However, I don't see other bug in your moz0.9.2 list "receive this treatment" (change to an extension scheme and turn OFF by default.)" I don't believe any of my other bugs are of the same magnitude. This is significant new UI. This is not a crash, a visual glitch, or a layout error. "if you do think other pref absoluete should also be as an extension as well, why they are not filed and in your moz0.9.2 bug list?" There are lots of imperfections in Mozilla. We can't fix them all at one time, however we can do our best to prevent sub-optimal solutions from being introduced. I believe this is the whole point of super-review. "Is this your "personal feeling" ? or is this based on marketing study? if no body need this type of functionality, then could you explain to me why yahoo.com spend money on http://local.yahoo.com/ to offer regiaionl information? (content pack switching is basically the client side equivlent here). Why a lot o users use http://digitalcity.com which provide the server side solution to the regional switching ?" This is common sense. My mother doesn't care, after I did my best to explain what this feature was (still don't think she got it). I'm sure that other internet users like her (and boy are there a lot of them) don't care. They're not here in this bug to back themselves up. That's been the story of Mozilla, those people we're actually trying to create stuff for have become lost in the noise of "I need a pref to set my context menu response speed," "I think we need a fibrillating doohinky," and "we need to switch content packs!" I agree with mpt. This functionality is the role of the content provider, which is the web server, not the browser. ">Generally Internet Explorer keeps out of their face, no wonder your customer never request this, they are using another product which do now have this feature." They're actually probably content with a browser that does what they're asking for (gets them where they want to go quickly and efficiently within their allocated 10-20 minutes) and doesn't bother them with crap they're NOT interested in. It's getting to the point these days when it's worth paying for software like that. Oh wait, we have IE.

ben: document inspector's preference panel crashes mozilla, i'm sure netscape, ibm, beonex, and eveyone else would love for this feature to be implemented only in preferences and to behave like that.

>After speaking with a variety of users I have reached that conclusion. Could you identify who they are ? >No such "scheme" is necessary, the technology of adding panels using >dynamic overlays already exists. Look at what Mail/News does, Could you kindly point out which file, which lines ? That will be easier for us to implement it. >what the Document Inspector does etc. timeless@mac.com 2001-06-06 17:01 -- >ben: document inspector's preference panel crashes mozilla , i'm sure netscape, >ibm, beonex, and eveyone else would love for this feature to be implemented >only in preferences and to behave like that. So... if what timeless said is true (inspector's preference panel crashes mozilla), we will crash the same way as inspector if we copy that code, right?

Has timeless debugged the problem and proven that any crashes he saw were in nsXULDocument or nsChromeRegistry? (I.e. the fault of dynamic overlays)?

Mitchell - Pls read Timeless's comment. "ben: document inspector's preference panel crashes mozilla, i'm sure netscape, ibm, beonex, and eveyone else would love for this feature to be implemented only in preferences and to behave like that."

i never blamed ben for the fact that document inspector preferences crashes mozilla. The point of concern is that an extension isn't tested by as many people so the fact that a basic function of it might crash the application could go unnoticed for extended periods of time. -- If document inspector was part of the main mozilla for the past 4 months I can guarantee that clicking it in preferences would not crash mozilla today (of course, i can say anything about a hypothetical past but this is a reasonable assertion). read back to mpt's comments <2001-06-06 00:21> It's possible that Netscape will be able to maintain ... working [stuff] for their distribution **(though unlikely, judging by their past efforts at similar features)**; but **the majority of Mozilla distributors would not have the resources to do this**, even if they shared Netscape's opinion ... The likelyhood of extensions maintaining a working status for any period of time is very low unless they are being distributed with nightly builds. it's just as useful to suggest that someone apply a patch from bugzilla. ben: chatzilla is an extension, it's often broken (currently it's about to receive another influx of upgrades -- which I applaud) does that mean you'd like to remove it from mozilla's distribution? fwiw document inspector will probably receive its own set of patches w/in the next few months that will make it better and fix known crashers, but as w/ all other extensions (even vixen?) it will be forgotten by the vast majority of users (including its author) and remain mostly untested. my comments in this bug should be read as devil's advocacy not as a guarantee of future events. Some other examples of extensions are transformiix and psm. Transformiix is currently broken on solaris and I think on windows and macos. Most people didn't notice or care, (I think it's even built and distributed by default on some of those platforms) -- but because it's can't resolve a link to cout or something it fails to load -- and no one really noticed until very recently. a few days ago a friend grabbed a solaris nightly build of mozilla and reported to me that it didn't appear to include psm. various people have noted that the strange psm build system has led to it being omitted and often unnoticed or untested for relatively long periods of time. It took 3-5 weeks for people to report that svg release builds were missing psm (this was an easy fix in a few cases).

I'm getting the impression that there is a belief that dynamic overlays don't work. Rest assured, they work just fine. Regardless of whether this feature is built by default in Mozilla and/or Netscape, it probably should be implemented as a dynamic extension.

Timeless suggests that features which are built by default will receive more QA and coding attention than features which are not. However, Mozilla's current code demonstrates that the amount of attention paid to a feature is dependent more on whether it is *useful* than on whether it is built by default. Example 1: Chatzilla. It's built by default, yet (as Timeless says) it's considerably more buggy and unreliable than the rest of Mozilla. This is because most people use Mozilla for the Web browser and the mailer rather than the chat client, so the chat client naturally gets less attention. Example 2: the Forms Manager. The current Forms Manager UI has been built by default in Mozilla since late last year, yet it is completely unusable on Mac OS. Only one of its panels displays at all. I first noticed this bug about five months ago, but I left it unreported as an experiment to see if anyone else was trying to use the feature. Apparently no-one is, because no-one else seems to have filed the bug. This is simply because, in its current overblown incarnation, the Forms Manager is a useless feature. People aren't using it, they aren't filing bugs on it, and volunteers (with the exception of Timeless, I think) aren't patching it. So, much as you might wish otherwise, you can't force people to test features which they are not interested in, just by building them by default. All you will achieve is increasing the code complexity, increasing the compile time, and increasing the download time, reducing the productivity of programmers and driving away potential testers and users. So I think it's totally unreasonable to have the `content pack' feature on by default, when anyone who wants such a feature will use the simpler, more convenient, more cross-browser-compatible, more portable, and more understandable server-side version (e.g. My Netscape) instead.

[reopening after accidentally resolving -- sorry]

Frank, please see: http://www.silverstone.net.nz/mozilla/dynolay.html (I'll eventually try and find a home for this on mozilla.org, but it's quicker to publish here for now). for details on the creation of dynamically overlayed UI. I created these steps based on the code in: http://lxr.mozilla.org/seamonkey/source/extensions/wallet/ and http://lxr.mozilla.org/seamonkey/source/extensions/wallet/resources/

http://bugzilla.mozilla.org/show_bug.cgi?id=65251: > This is simply because, in its current overblown > incarnation, the Forms Manager is a useless feature. FYI, I find it one of the more useful features of Mozilla. > People aren't using it, > they aren't filing bugs on it, The reason I am not filing bugs on it, is because it works perfectly for me.

ben: >Has timeless debugged the problem and proven that any crashes he saw were in >nsXULDocument or nsChromeRegistry? (I.e. the fault of dynamic overlays)? While timeless may not debug and prove that the crash is in nsXULDocument or nsChromeRegistry, it is true that we my have risk to cause new crash by clone that code, right? It is not important the problem is in nsXULDocument or nsChromeRegistry or now. It is important that that is not a good example my team should follow. mpt: >Example 2: the Forms Manager. The current Forms Manager UI has been built by >default in Mozilla since late last year, yet it is completely unusable on Mac >OS. If mpt said is true, then form manager is neither a good sample code, right? While the problem he describe may have nothing to do with dynamic overlay, it simply mean that I may have higher percentage to see the problem on mac if I follow that code, right? hyatt: >I'm getting the impression that there is a belief that dynamic overlays don't work. hyatt, I don't think that is the assumption. It just we are not sure where can we find a good sample code for the overall "extension" mecahism (including dynamic overlay and other additional steps) ben ask us to do. ben: >Frank, please see: http://www.silverstone.net.nz/mozilla/dynolay.html Thanks. Quickly read it, seems not trival. Will try it today. jbetak is on vacation. Not sure how fast nhotta and I can catch up this. mpt: > you can't force people to test features which they are not interested in, >just by building them by default. YES, but in the other hand, you can block people to test features which they are interested in, just by building them OFF by default. So... build them ON by default cannot force people to test. Bulid them OFF by default can BLOCK people to test it. Do you want to BLOCK people to test an important feature . mpt: >> 10 years from now, if we make this feature successful, then they will ask >> you. >You mean, like Netcaster? No, I mean like the FRAME feature we add in netscape 2.0 in late 1995 (I bet your internet cafe customers didn't ask you how to print frame before 1996, right? simply because it does not exist untill we add it in 1996). I mean like cookies we add in netscape 1.0 I mean like SSL we add in netscape which form the base of eCommerce I mean like JavaScript brendan add in netscape 2.0 in early 1996 ( I ben your intertnet cafe customers didn't ask you about JavaScript before that, right. Simply because it does not exist untill we add it) I mean like read/write HTML mail like what we add in 2.0 (read html news in 1.0, read html mail in 2.0) in 1995. I still remember people complainted to us that their mailer cannt read the html we send out that time. But how many mail you received are in html these days? I bet your internet cafe customers didn't ask you how to read/write html mail in 1995- simply because it does not exist untill we *create* (not really true, maybe I should said mass deploy ) them. Did your internet cafe customers ask you about these features in 1995 before we add them ? I believe not. Does your internet cafe customers ask you about these features now. Maybe they ask - which mean the feature is still not seemless enough, maybe they don't- which mean the UI is simply enough that it is really easy to understand now. But no matter they ask or not, we have to recognized they are all very basic imporant the current www based on. I certainly hope this feature will be used by many people. We can make that happen if we do it right and consistently build a strong support mecanism behind it.

mpt: >Frank, you're proposing adding this feature to Mozilla, so the burden of > proof is on you to convince the module owner that it would be useful in > default builds 1. this is not the case, my team are currently work on this bug simply ben's manager ask us to help ben out. The one who propose adding this feature to mozilla is jaimejr@netscape.com . My team, jbetak+nhotta+ftang involve simply after vishy (ben's manager) request our help in pdt . We are here to help ben to reduce his work load. 2. As of burdent of proof- it simply on jaimejr. However, I help to point of some of the proff already. We already show many evidence in the comment of this bug report, including a. an important mozilla customer, Netscape, think it is an important features. b. an important mozilla customer, IBM, think it is an important features and want it for their OS/2 build also (see Michael Kaply 2001-06-04 16:27) c. I also point out that yahoo invest on local.yahoo.com and aol have digitialcity.com . And there are many other webside which allow regional/content switching on the website, and millions of internet user already using them daily. This feature is an client side clone of that kind of setting. nothing new except it is in the client side. What other data you want to proof it is an important feature? ben wrote: >My mother doesn't care give me the telephone number of ben's mom, I am willing to call her and explain this feature to her. I believe that I can convience her it is an importnat feature and she will agree with me. If it is what it take to convience the mozilla UI owner these days. ben: >This is common sense. Is gravity a common sense before Newton? and defintly, so far, we have not have "common" sense together yet here about this bug. The reason that I ask my team to work on this bug is not based on common sense. Instead, it is base on a request from two colleages (jaimejr and your manager vishy) to help. I work base on trusting domain experts, marketing expert jaimejr , who think this is an important feature after he talk to customer/distributor, and listenting to my customer/partner, mkaply from IBM . If I follow my common sense, then vishy's team simply should finish this long time ago without our involvement.

I'm not interested in joining this discussion, but please stop using that rogue crasher as any sort of evidence that it shouldn't be in /extensions until you show some evidence that it has anything whatsoever to do with dynamic overlays (and that it still exists). You risk crashing in anything you do, that argument is ridiculous.

blake >please stop using that rogue crasher as any sort of evidence that it > shouldn't be in /extensions until you show some evidence that it has > anything whatsoever to do with dynamic overlays blake- you totaly miss my point. My point is I cannot find a good example to follow to implement what ben ask us to do. I am not saying it should not (or should) be in /extensions based on that. I simply say if ben want us to do so, he need to tell me a good example. And so far, I didn't get a good one yet.

ben said yesterday to me, bobj and jaimejar in the telephone conversation that the change from the current patch to make it as an extension is very easy to him, it will take ben 10-20 minutes to do that. Ben: is that a good estimation for you (not for us, but for ben) ? do you need to adjust such estimation? If not, since my team already help vishy this much, can you help us by spending that 10-20 mins to make the current patch work as you expect? I will very appreciate if you do so. My estimation is that it will take me (ftang) about 10 hours to make it work since I need to learn overlay/rdf/xul all these stuff. vish: since (1) jbetak is on vacation this week, (2) it will take me about 10 hours to learn that, (3) ben only have 3 moz0.9.2 bug now - two in P3 - 79889 and 79938 and one in P1, and (4) the only moz0.9.2 P1 ben have - 84344 cannot be check in after we branch moz0.9.2 at least untill 6/26, (5) this is an moz0.9.2 P1 bug, can you nicely to ask ben to spend that 10-20 minutes to change the current patch to such extension scheme ?

I do not believe that Ben should make all changes in this area, the knowledge must be distributed. I also recognize that Ben's info on how to do this is new (last night) and untested. So perhaps it is a 10 hour job as frank asserts. Therefore, I have asked scc to work with frank to learn how to do this. scc can assist in understanding ben's materials if they are incomplete or unclear, or in reviewing the code afterward. this should also improve Ben's materials and make it easier for others to learn how to create dynamic overlays in the future. mitchell

I wrote: > If I follow my common sense, then vishy's team simply should finish this > long time ago without our involvement I appology for this. It is my mistake that based on wrong assumption that the bug was assign to vishy group. Please forgive me and I am trully sorry for my stupid comment above.

Two file are missing (ref-content.dtd and all.js) from jbetak's patch (06/05/01 18:56). I added a patch (06/08/01 17:49) for those files.

Vishy - Per our conversation this afternoon, marking this one as PDT+ meeting this afternoon. PDT has requested that your team do the "extension" work over the next 3 working days. Alternatively, we should accept the "fix in hand" from jbetak. Can you reassign this one to Ben to get the "extension" work done?

It is not my responsibility to bring this patch up to standard required by Navigator. I have other, more important bugs. The current patch will not be accepted until it meets the standard required.

looking at the new patches: 'changes the browser Home Page' would probably sound better as: 'changes your Home Page'

pdt+ base on 6/11 pdt meeting.

>It is not my responsibility to bring this patch up to standard required by Navigator pdt officially told your manager to give you such responseibility last Friday. I believe your manager vishy called you monday afternoon about this issue.

Ben is going to convert this to an extensions patch by 06/13/2001.

Attached are patches that make this an extension. Modification was also required to fix some of the code's usages of javascript:alert (which should not be used from chrome) and change them to nsIPromptService::alert

"pdt officially told your manager to give you such responseibility last Friday. I believe your manager vishy called you monday afternoon about this issue." Thanks Frank, I'm sure you're elated.

The way the UI for this stands right now, I do not believe this is ready to be checked in to either the Mozilla or Netscape trees. First of all, the term "content pack" is completely misleading and inaccurate, as is the usage of the term "content" to describe this feature. It will lead the user to believe that these packs somehow enable the user to customize the contents of the windows themselves. The text even refers to changing the "contents of toolbars." When I read this, I'm led to believe that these content packs enable me to get a different toolbar layout or button configuration, e.g., pictures vs. text toolbars or different buttons all together (print/search/etc.). This problem is further compounded by placing the panel under the Appearance heading in the preferences tree. In reality a content pack does not alter the appearance of your window at all, unlike everything else in that prefs heading, so why has it been placed there? Moreover, I do not understand the need to bundle the content pack UI into the browser by default. This should be implemented as a dynamic downloadable extension and should not be part of the Mozilla or Netscape builds by default. It seems like we could have a menu item that linked to a Web site (similar to what we do for the "Theme Park" for downloading skins) that could automatically download and install the "content pack UI" (ugh, I hate the term content pack) if and when the user downloads a "content pack" from a Web site. Before I can give an sr to this bug, I believe the UI for this feature needs some serious re-evaluation.

For the record, I see a horrible practice happening in this bug. A patch was submitted, a super-reviewer posted (IMO) quite reasonable objections, and then the bug was handed to that super reviewer who was then forced (through the Netscape management chain) to fix those things he found objectionable, rather than having the original author(s) of the patch fix the problems. I plan to raise this issue at the next mozilla.org super-reviewers meeting and to upper management within Netscape. It is not the job of a super reviewer to do another engineer's work for him, and I find the way Netscape management was used to perpetrate this maneuver really appalling. Perhaps the engineer(s) who wrote the patch should make an effort to respond to super reviewer comments and to learn the technologies required to produce a patch that passes review. I see a lot of hand-wringing in the bug and feeble finger-pointing at the underlying extension technology itself (which has worked flawlessly in the existing product for well over a year). These excuses seem to have been used by the authors of the original patches to circumvent their fundamental responsibility, namely responding to the original super-reviewer's criticisms with updated patches.

Copying alecf so he can read David's comment.

Even though I disagree with Hyatt (i.e. Themes is what refers to UI changes such as layout and button changes in the application, and I think that is pretty clear), I am openly soliciting assistnace in the naming. Adding Rudman to cc: list for help with the word "Content Pack". Please Note: The term "Content Pack" refers to any Web Content within the product that customized by the user (e.g. As deep as changing Sidebar, Personal Toolbar, Bookmarks, and Search engine for those who begin with a new profile when they select the pack). We have used the word "Region" pack in the past, but the utility fot this technology, is that "Content" can be specified by a distributor, developer, partner, or Content Developer that is more than geogrpahicly defined bookmarks, sidebars, personal toolbar, etc. Hence, we could have Regional Cotent packs for L10N reasons, and packs offered by Disney, Toys R US, Sony, Niclodeon for the Toy Factory theme - - For a kid Theme, we could specifiy links to Content Developer sites that are kid friendly, while providng that user an improved browsing experience, customized to their needs. David - I appreciate the open comments, but I'd also like to hear a suggestion for the name of the packs. To date, everyone has opined about the name, but nobody has offered a better alternative. Any ideas?

Produce a list of everything that this feature changes on the fly, and post that list here. With that list, we can look for some common thread, consult a thesaurus, etc ;)

By list, I mean itemized: - Throbber URL - Search button URL - Default Home Page etc.

hyatt: what is ben's responsible in Netscape?

Speaking only for myself (not for mozilla.org nor Netscape), I must agree with David Hyatt. There are plenty of engineers submitting patches which will impact the UI, and only one mozilla UI owner. Having Ben Goodger do their work for them in bringing their patches up the level of quality required for check-in is not a solution that scales. This is work that could have been done by the engineers in question perhaps as early as last week, then their work could possibly have already been checked in by now. Frank, do you really want Ben Goodger's engineering time to become the gating factor for all your future check-ins? I imagine you don't. Do you really want to start the trend where _all_ engineers regularly require some _one_ person to complete the UI for their check-ins before they can be considered complete? Of course not. Perhaps you think you (or your team, or the orginal engineers ... whomever would be responsible for this work) are overburdened with engineering (and perhaps management) tasks, and it is right for Ben to do this work for you. That may well be. It certainly seems as though, currently, at least you and Vishy agree that your (again, the plural, I'm not singling you out, Frank) time is more valuable than Ben's. This is well within Netscape's rights. My personal opinion, however, is this is a short-sighted step in the wrong direction at the top of a slippery slope, and for no better reason than your discomfort at exploring an unfamiliar solution. I hope you get over your discomfort ... I really do. Because if you don't, Ben's time will become so much more valuable than any other engineer that not even Ben himself, let alone Netscape, will be able to afford it. This will not lead to Netscape's success, nor to mozilla's. In particular, moving forward into a world where we have significantly less UI help from Hangas' group and from Ben Goodger, et al, than we would like, we need to be _more_ vigilant, and require patches that impact the UI to meet the criteria of the UI module owners. Ben's suggestions, documentation, and examples _should_ have been enough. We don't ask module owners or super-reviewers in other arenas to rewrite the submitted patches. They are rarely even up to the task of providing the documentation Ben provided. Even as `politely' as this was handled, in retrospect, civility prevents from expressing my fairly visceral opinion of the entire affair. It would be one thing if the work was somehow beyond the original engineers, or wasn't trivial, or wasn't something that for many things in the future must become the norm, or if Ben had volunteered, or if the contributing engineers had exploited the mozilla.org resource (me) that was offered to them, or if people hadn't used Netscape's management chain to circumvent all reasonable paths of resolution. I am often called upon to help find the middle ground. No middle ground was found here. And worse, the next time I find myself in a situation where I must find a middle ground with Netscape among the contenders, I will not know how to defend Netscape, should that become necessary, against the evidence in this bug. I hope that Netscape takes this to heart and can use this experience to better evaluate in the future how to get the job done. If we at least learn from this mistake, it won't have been a total loss. At this point, my _personal_ opinion is that _any_ engineer who has read through this bug should either know how to create a dynamic overlay or should be willing to give up their check-in privileges in shame. It's not hard; and it's part the job.

While I agree with David and Scott's comments in theory (module owners should not be responsible for clean up/completion of other's code) it is appropriate for them to assist if it would be more efficient due to specialized knowledge or if it is implementing a new coding standard or practice where they should lead by example. This bug fell into both of these categories in terms of appropriateness of who should do the extensions work. It was also appropriate based on work load/criticality of bugs as well as expectations set upfront.

So we're currently blocked on r/sr for this, yet it is P1. I can modify the patches in my tree to remove "content of toolbars" from the string, but we've yet to hear from doc on a better name for "Content Packs". We seem to be having a lot of trouble deciding on what this feature covers, or at least the text representation for what it covers. I again request a list of functionality modified, so that doc can assist us in developing a suitable text description. David, do you have any other specific requirements for this to obtain your super-review approval?

As Ben says, there is some difficulty in deciding what "Content Packs" covers. I'm not in a position to offer an opinion on terminology without clarification about the functionality being described. I just printed out this bug, and it's 32 pages long. I'm not going to attempt to go through every comment to see if I've captured every nuance. Jaime, it would be best if you explain to me in person what the term really encompasses.

Left message and will work with Steve today to develop a new name, or keep the same one. Here's some information on Customization Packs (formerly Country Picker), from Tao's original specification. Glossary Regional Content: The content services that are provided by remote web servers. In Netscape 6 (PR2), this includes built-in URLs, Taskbar, Search menu, Sherlock files, Bookmarks, and Sidebar Defaults. Language Pack: all localizable resources including Regional Contents and other localizable resources such as UI language files. Profile-bound localizable resources: resources that are bound to a particular user profile. Their initial values are obtained from the chrome directory in profile creation and might be customized thereafter during user sessions. These include localizable user preferences, Bookmarks, and Sidebar Defaults. Obvously, some of this information is latent, and the value and extension of "Regional Packs" has grown to support more than regional content. Pls see my comments from 06.13.01.

Ben - Pls summarize blocking issues, so we can resolve them. Is it simply the name of "Content Packs"? If so, Rudman and I will propose new names later today.

"Content packs" is better than anything else I can think of. But I'm biased---German consulted me back in February, and I opted for Content Packs then (I had forgotten until now that I already made a suggestion for the term). So it may not be the most intelligible term in the UI, but unless anyone can offer a better solution, I recommend keeping it. One other consideration is that there will be a Help button on the panel, which can be used to access context-sensitive help (true for the commercial tree only for the time being, but likely to be true for Mozilla soon). Presumably, the help can explain items that may not be clear in the UI. I hadn't seen the UI until now. I absolutely agree with Ben's comments. So I'll offer some suggestions for wording. For the Appearance panel, as depicted in http://bugzilla.mozilla.org/showattachment.cgi?attach_id=37110 "Choose a language for Mozilla. The setting affects the language for text that appears in dialog boxes, menus, toolbars, and button labels. You must restart for a new language setting to take effect." For the Content Packs panel depicted in http://bugzilla.mozilla.org/showattachment.cgi?attach_id=37109: "Selecting a new content pack changes items in My Sidebar and the Search menu, and changes the home page, certain bookmarks, and other items. You will not lose bookmarks and other items that you have customized when you switch content packs. You must restart for a new content pack to take effect." If "certain bookmarks" needs clarification---to indicate that factory defaults (as we used to call 'em) are different per content pack---we could use "certain preset bookmarks."

Anything else Ben?

Copying hyatt and trudelle on this. Hyatt, can you please itemize an other items that aren't addressed by rudman's comments? I've applied his changes into my tree.

Ben - whats an ETA on this? thanks, Vishy

extensions part is now in the tree. hyatt sez: "sr=hyatt" the patch was originally produced by jbetak so r=ben. Need to get a=, mailing drivers.

a= asa@mozilla.org for checkin to the trunk. (on behalf of drivers)

ugh. my tree won't build. I'm pulling a new tree and applying patches into it, will check this in in the next day.

a=blizzard on behalf of drivers for 0.9.2

feature checked in.

ben: as far as I can see, you haven't checked this in on the branch. At least, I can't see it in the build, and bonsai claims you haven't touched the branch in the last week. You have checked it in on the trunk, but I can't see it in 2001-06-22-11-trunk or 2001-06-22-18-0.9.2 on Win95. What gives? :-) Gerv

I don't think we had yet branched when ben checked this in so a checkin to the trunk should have been sufficient.

I see the UI language choice in Appearance, but no Content Packs preferences, and no pref-contentpacks.xul in my chrome directories. <mini-rant severity="mild"> When people close a bug with "feature checked in", could they please say exactly where, particularly near or at branch times, and if there is any possibility that the feature is Netscape-only?</mini-rant> Gerv

Why? This feature is not netscape only. If it were, this bug would have been in bugscape.

Well, you and I both know that doesn't always work. But can you please explain (for the hard of thinking, such as myself) where the content pack XUL is (both in the chrome directory and in the UI) because (I repeat) my unjarred nightly's chrome doesn't seem to have it. Gerv

Ben - I do not see "Appearnce | Content" in Prefs for Content Packs. Did we miss it? Should we file a bug to correct this in the branch?

It looks like ben add a new jar file called content-packs.jar But I don't think any installer file changed to put it into installer Do we need to change something inside mozilla/xpinstall/ ? ns/xpinstall. reopen the bug.

Ben - could you check in the packaging change today? thanks, Vishy

a=chofmann branch and trunk

ben has checked in the packaging changes. please verify.

Reopening - Still do not see "Appearnce | Content" in Prefs for Content Packs; only UI Language choice is available. Checked on 2001-06-27-09-trunk and 2001-06-27-10-0.9.2 using WinMe-Ja.

If you have time, the content pack text has some typos: 1) needs comma after My Sidebar 2) changing should be capitalized 3) browser should be Navigator 4) home page is lower case Suggested edit below: "Selecting a new content pack changes your Navigator home page, the content of toolbars, the Search menu, My Sidebar, and other items. Note: Changing content packs requires you to restart Mozilla."

The UI shows up in zipped mozilla builds. This appears to be an installer-specific issue. I checked an installer build and the jar file was present, but the appropriate lines in installed-chrome.txt were not present (mozilla and netscape builds). Investigating...

pushing out. 0.9.2 is done. (querying for this string will get you the list of the 0.9.2 bugs I moved to 0.9.3)

Ben, this is PDT+ bug. Tomorrow, on Tuesday, we'll try to build the first RTM candidate. It would be good, if this could be resolved ASAP.

Ben - could you get the reviews for this on Thursday and speed this into the tree. thanks, Vishy

My theory as to the nature of the correct fix checked into trunk. Awaiting verification there before landing on branch.

Jon, please verify if this has been fixed on the trunk build.

For documentation purposes, please verify that no changes are being made to the Navigator>Languages panel as a result of the changes to the Appearance pref. panel (Content Packs and Appearance). Thanks...

Doesn't appear fixed as of 07-05-06-trunk. There is now a Region panel under Appearance, but the title is blank. Also, the only choices in this panel are "OK", "Cancel", and "Help". I will attach a screenshot. Doesn't appear that there were any changes in the Navigator>Languages panel. I'll attach a screenshot of that as well.

I merged Ben's latest packaging changes onto the branch as well (we verified that these changes worked on the mozilla trunk installer). We could not verify with the commercial installer due to some difficulty building it but are now confident that this is finally over. Jon Rubin - could u please verify this asap. thanks!!

Hi, Ben and Vishy: Many thanks for the extra effort to get this in. We appreciate it.

Verified on 07-06-06-trunk on WinMe-Ja; verification on other platforms and branch to follow soon. In the Content Packs panel itself, no "Apply" button was found; this appears dependent on the patch to bug 65241--awaiting confirmation from Ben about this.

65241 is unrelated to an 'apply' button. The rationale for not having an apply button was that a common mistake has been to select an item and hit OK, expecting the change to take effect rather than hitting apply, so this is the behaviour was that which was implemented. We can augment/replace this with an apply button if desired.

Talked with Frank/Juraj/Ben, yes its best to not have the apply button and let changing it in the tree and then hitting OK be the way to make it apply.

Copying my last comments from bug 65241 (2001-07-08 21:42), which has essentially become a dupe of this bug as of 65241's summary change on 07/06: My observations are the same as Sairuh, except on Linux. I tested branch and trunk builds on Win32, Linux, and Mac as follows (on each platform, trunk results matched branch results): WinMe-Ja, 2001-07-07-12-0.9.2 comm and 2001-07-08-10-trunk comm: Content Packs panel does appear, and Download More works. However, choosing the new region in the "Installed content packs" window does not result in the "Restart NS6" message after clicking OK (the message does still appear if selecting the region via the View menu). The region does change correctly if the browser is restarted. Linux Redhat 7.1-Ja, 2001-07-08-04-0.9.2 comm and 2001-07-08-06-trunk comm: Same results as above on WinMe-Ja. MacOS9.1, 2001-07-08-03-0.9.2 comm and 2001-07-07-08-trunk comm: Same results as Sairuh: Content Packs panel does not appear in Prefs. Reopening this bug for the problem on Mac. Jaime, could you please confirm that the fix as verified on Win and Linux is sufficient without the "Apply" button? Thanks.

Was the "Restart" message not included with Prefs because of Bug 66909?

Jon - This looks pretty good to me at first glance, but let's get togehter later today, and review it together. I want to make sure, we close out all pack related issues ASAP.

This bug is just too long and omnibus at this point. please open any remaining issues as new and specif bugs - we shd not just inherit the PDT+ nature of this bug into any remaining issues . thanks!

-> meant to mark this fixed.

Vishy - Unfortunately, I don't think this one is dead quite yet. Jonathan is telling me this is quite wroking on the Mac OS. Suggest we Repoen, until it is completely resolved.

yes, using 2001.07.09.03-branch comm bits on Mac, the Content Packs category is still missing. not a problem with the 07.09-branch comm builds on winnt or linux.

We will fix 65241 on mac today (7/10, appearing in 7/11 builds) on trunk and branch and that shd clear this up as well.

reopening, setting platform to Macintosh.

this has been checked in and so fixed.

the 2001.07.11.13-comm *branch* build on Mac contains the Content Packs category. however, the 2001.07.11.13-comm *trunk* build on Mac is *missing* the Content Packs category altogether --there's not even a blank line for it in the tree. spoke with blake who sez this bug should've fixed this, so i'm reopening it. i skimmed over the commercial and mozilla [trunk] tboxen, and i couldn't find a check-in by ben or vishy referencing this bug, either. (unless i missed it/wasn't looking for the right info. :)

Yes, I saw the same thing on 07-12-08-trunk-comm (Content Packs category missing) and 07-12-09-branch-moz (Content Packs appear). After Paul's checkin for bug 65241, he left this comment: ------- Additional Comments From Paul Chen 2001-07-10 14:46 ------- I've just checked in on the branch. I leave it up to Ben to check in on the trunk. Marking this bug fixed. -------- I did not see any additional messages about a checkin to the trunk. I will reopen bug 65241 since that bug cannot be verified without the Content Packs panel.

I think that this bug now says that its fine on the branch, but still broken on the trunk. Removing nsBranch and PDT+ designations therefore as we are good to go for RTM. Ben - please merge the last packaging/makefile change onto the trunk

Vishy, sorry if my earlier comments were not clear. Yes, you are correct--the Mac branch build is fine now, but the trunk still doesn't show the Content Packs panel. Just to be sure, I double-checked today's builds (Mac comm. 2001-07-13-03-branch and Mac comm. 2001-07-13-04-trunk).

checked in to trunk. fixed. *passes out*

Verified on 07-16-04-trunk on MacOS9.1. Will mark bug 65241 as verified also.