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

Since we are separating language UI from regional content, we will need to change the View menu to reflect the change. I propose we: 1) Remove "Set Language/Region" from the View menu 2) Add "Select Language" and "Select Regional Content" to the View menu, under Apply Theme. Thereby grouping all Navigator customization features in one area. Nominating for nsbeta1. ------- Additional Comments From Jaime Rodriguez, Jr. 2001-01-02 17:57 ------- Adding nsbeta1 and intl keywords.

------- Additional Comments From timeless@mac.com 2001-01-02 21:13 ------- to bleeping with this- Request permission to remove these menus from mozilla. If Commercial wants them they'll probably have to keep them in their tree. Waiting for mpt to tell me he disagrees. Ben I'd like your input too. ------- Additional Comments From Matthew Thomas (mpt) 2001-01-02 22:38 ------- (1) can not be done. There isn't a `Set Language/Region' item in the View menu (or any other menu, for that matter), so it can't be removed. (But see also bug 61162.) (2) should not be done. Including these two new menu items would be very bad. In the list of things users will do most often with Mozilla, changing their UI language and their regional content will come in at about 7043 and 7044 on the list. No way do they belong in the menus. ------- Additional Comments From Jaime Rodriguez, Jr. 2001-01-03 08:51 ------- Commercial does want them. There is a "Set Language/Region" item in the Commercial release of 6.0. ------- Additional Comments From tao@netscape.com 2001-01-03 12:24 ------- The Mozilla equivalent of Netscape6's "Set Language/Region" menuitem is "Languages and Web Content". This bug calls for moving "Set Language/Region" and "Apply Theme" into a sub-menu group: "Customization". The UI details is yet to be defined. >(2) should not be done. Including these two new menu items would be very bad. >In the list of things users will do most often with Mozilla, changing their UI >language and their regional content will come in at about 7043 and 7044 on the >list. No way do they belong in the menus. Not sure if this is true for international users. ------- Additional Comments From timeless@mac.com 2001-01-03 13:58 ------- imo, menus are for quick changes that require little thought and no preview. Users should not need to make multiple visits to the same part of a menu to get something they like. In English, that means if the user is likely to need to change 5 things to be happy [Theme, UILanguage, ProvidedContent Region, Prefered Browsing Language, Fonts for web content] then the user needs a dialog. This dialog content fits well w/ the current preferences dialog and there does not seem to be any reason to use the menu system. I know moz has languages/web content, it's a misnomer. I think it really meant languages/provided content. questions that mpt and co would want you to answer: Does the user intend to frequently change these settings? Will the user need to see a preview before making a decission? Will the user be able to recognize this item when it's written in the wrong language? This last one is probably ****ing, because I know that I can't read "Languages/Web Content" if it's written in arabic. However, my experience w/ Netscape4 tells me where the preferences menu is, and it also hints about that dialog's layout. I can imagine finding my way to something that said English. The others also argue against your cause. The average user probably changes ui languages less than .1 times per install. This is based on the assumption that mozilla picks the default language based on the system default instead of assuming everyone uses English. And if you haven't filed a bug to allow mozilla/netscape to ask for permission to retrieve a translation based on the user's system default then please do so now. ------- Additional Comments From Matthew Thomas (mpt) 2001-01-03 14:01 ------- What is an `international user'? Is that one of those weird people like me, who have the audacity to live somewhere other than the US? Or is it someone with a split personality, who is compelled to change the language of their Mozilla user interface every hour or so, and so needs a menu item for that express purpose? A feature which will only be used only once or twice in the lifetime of a Mozilla user profile simply does not deserve its own menu item, regardless of how badly the developers of the feature want to show it off. I suggest this bug be wontfixed and bug 64147 be fixed instead. If `commercial' (by which I assume you mean Netscape Communications Corporation) want to confuse their users by putting such a menu item in their distribution, they can file that in their own bug database. ------- Additional Comments From tao@netscape.com 2001-01-03 14:49 ------- 1. I agree that "Set Language/Region" is more proper than "Language and web Content". We could take the opportunity of revamping "View" menu to fix it. 2. Prefs dialog is certainly the best place to change multiple user preferences at the same time. However, menu item has the advantage of exposing the feature to end users. Placing language/region setting menuitems adjacent to international related menuitem improves their visibility. 3. Answers to your questions: >questions that mpt and co would want you to answer: >Does the user intend to frequently change these settings? For language/region, it depends on whether you are a multiple-lingual person and whether this client installation is shared by person (family) with multi-culture background. The original goal is to provide the flexbility of switching UI languages and regional content with the same client installation. In the past, we need different client installation to do so. For road warriors that make international trip, the capability of switching regional contents should be convenient. >Will the user need to see a preview before making a decission? As you suggested, menuitems are for easy access and tasks that do not need preview. Will the user > be able to recognize this item when it's written in the wrong language? Not sure what you meant. But, if you are referring to the UI language, the rationale is user won't switch to a language that s/he does not read. 4. Using system locale as the default is a reasonable solution for picking the default UI language and regional content. See http://bugzilla.mozilla.org/show_bug.cgi?id=44070. 5. > What is an `international user'? Please pardon my terms. I obviously used the wrong word. I meant "multi-lingual" or multi-cultural users like me. One usage of this feature is the kiosk mode client installed in public area/resort like Disney world and internation airport. Net appliance is good candidate, too. ------- Additional Comments From Reinout van Schouwen 2001-01-11 15:45 ------- I'm not quite sure this is the right bug to add this question to, but I hope so. The newsgroup Date column displays time in AM/PM format. I'd like to have it in 24h format. I don't mind if the Mozilla interface is in English but having an option to use different date/time formats would be nice...

This is starting to get pretty complicated. Now there is a request for adding time display prefs too. I thinks this calls for a UI that would let users define "Locales" in a locale manager, that is you capture settings under one 'Locale" name, that you will be able to switch using the view menu. Most likely users will know which combinations they need most frequently, there is no need for exposing all the complicated setting in the view menu and thereby penanlizing mono-lingual users.

> This is starting to get pretty complicated. Now there is a request for adding >time display prefs too. There are other locale categories such as MONETARY, CTYPE, COLLATE, etc. Changing them either statically or dynamically is a more complicate issue than changing chrome locale provider. It's more of an enhancement request. >I thinks this calls for a UI that would let users >define "Locales" in a locale manager, that is you capture settings under >one 'Locale" name, that you will be able to switch using the view menu. Most >likely users will know which combinations they need most frequently, there is >no need for exposing all the complicated setting in the view menu and thereby >penanlizing mono-lingual users. As you suggested, it probably is not a good idea to put settings of all locale types in View menu. A better place might be in the Prefs dialog. However, the short term solution is to provide quick switch of chrome locale provider. Let's attack the "Locale Manager" UI in future release.

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.

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.

Reassigning to German for UI specification.

friendly reminder that UI freeze is March 1st, with approved changes only till March 15th

What proportion of Mozilla users meet all four of the following criteria: (1) regularly travel to different towns/countries; (2) take their computer with them when travelling to a different town/country; (3) use content provided by mozilla.org (or netscape.com, or whoever), rather than their own selection of bookmarks etc, to keep up with local news/events; (4) do not want to keep up with news/events in their home town/country -- preferring access to these to be deleted and replaced with access to news/events in their destination -- when travelling? If that proportion is less than 20 percent (and I suspect it's less than 0.5 percent), I'm going to kick this bug into the Derivatives > Netscape 6 component. I don't mind such menu items being put in the `View' menu for Netscape users to laugh at (though I'd certainly advise Netscape against it), but please, please keep them out of Mozilla.

Triage Team marking nsbeta1+ and 0.9

Chaning the qa contact on these bugs to me. MPT will be moving to the owner of this component shortly. I would like to thank him for all his hard work as he moves roles in mozilla.org...Yada, Yada, Yada...

Adding Andreas to cc: list.

Adding Yuying to cc: list.

Changing milestone because German is on vacation until we close for 0.9.

Paul - I guess we will have to wait for German, but we defintely needed done ASAP, so we can get some testing cycles on the changes to the feature. Question? - German finished the spec, is he also writing the code, or is that something Ben does?

German - Tao had indicated to me last week, that all his bugs were now accepted by Ben to resolve for M0.9.1. This one looks like it hasn't been picked up?!?!?! Ben - Will you accpet this one, or should I get someone in ICP to fix it? Adding ftang and bobj to cc: list. Bob - Tao said, you would be the best one to help in his absence.

Assigning a P2 | Blocker to this one. It needs to be fixed ASAP. Changing "Select" to "Set". Menu listing should now be "Set Language" and "Set Region". Vishy - This one is our Number 1 priority. Please see if we can get this fixed this week.

I dont think we can do it this week. This is the first I'm seeing this bug.

Jamie, Vishy, German, please see mpt's comment above. This should not be implemented until that question is answered. Please don't use some Netscape secret freeze date to rush in changes to the UI which have standing objections. Thank you.

reassigning to nhotta for review.

Asa/MPT - Code to seperate the Language UI from Content has already been checked-in. The reuqested UI changes address these changes, so that feature is not broken, and the user can customize their settings, much like Theme switching.

jaime, you are talking about adding items to the UI which currently aren't there, correct? If that is the case and there is a standing objection from mpt or questions still to be answered about the addition of this menu item, then this is not sufficiently ready for checkin. Your comment seems to imply that this is the only, or already decided upon (which it is definitely not) method for making the existing feature available to the user. That is clearly not the case. German hasn't even yet responded to your requests for a spec on 2/23 and his prior commented assumption that this was similar to themes was challenged by mpt and no followup has happened.

Asa - The UI already exist (see View | Set Language/Region). The feature already exist. This is an enhancment to seprate the Language UI from Content Packs. Pls see bugzilla 76551 which has been logged against the feature. German - Please attach your spec to this bug.

I may be way off base with this but isn't it the case that you're plan is replacing one rarely used menuitem with two rarely used menuitems and mpt's and other's suggestion is that we don't want to add menu items (one becoming two is adding a menu item) for tasks which most users are very unlikely to use with any regularity. I've seen bug 76551 and it is clear to me that the functionality is currently inaccessible. What isn't clear to me is why you think that two menuitems on the view menu is the only way to expose this functionaliy. That it is currently unavailable is not justification for adding access points to inappropriate places in the UI.

I think a comment from German n 2001-02-23 in Bug 65253 is pertinent: --- "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." --- While I agree that changing Region Content Packs would probably be a much more frequent activity, I would say that changing the UI language could be something that would be as frequent as changing the profile, as in the case where 2 people sharing a computer are fluent in two different languages. I would just add that another browser out there forces the user to click through 3 windows (internet options>languages>change) before the UI language can be changed. This can be quite cumbersome--something I would steer clear of here.

and Ben Goodger's response to German (from bug 65251): ------- Additional Comments From Ben Goodger 2001-02-28 01:05 ------- 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. MPT, the owner of the UI Design Component and Ben Goodger, the owner of the Mozilla UI have both objected to this. They have both stated that there should be _no_ View menuitem. Not one. Not two. None.

Reassign to vishy.

Look, I've been really nice, and waited very patiently for someone to produce a spec, or to explain why Mozilla would need to care in the slightest about which region a user is in, or even to explain what the smeg `regional content' *is*. I've been operating under the assumption that `regional content' is a set of default bookmarks and sidebar panels, and that the premise of this UI is that users are somehow going to be appreciate their own selection of bookmarks and sidebar panels being obliterated in exchange for mozilla.org's selection of bookmarks and sidebar panels devoted to a given `region'. I would love to be proven wrong on this point, because then this RFE (it's not a blocker, it's an RFE) would make a whole lot more sense. But all I've gotten so far is handwaving about `addressing' back-end changes, and dodgy comparisons with the `Apply Theme' menu item (which shouldn't exist either). > I would say that changing the UI language could be something that would be as > frequent as changing the profile, as in the case where 2 people sharing a > computer are fluent in two different languages. So, why not make UI language part of the profile, so that people don't have to change two different things when switching profiles? And if that is the case already, why do you need separate UI for it elsewhere? If this is just for convenience of i18n debugging, surely it should go in the `Debug' menu instead? > I would just add that another browser out there forces the user to click > through 3 windows (internet options>languages>change) before the UI language > can be changed. This can be quite cumbersome Well of course it is. It's a basic UI principle that items on the top of the list of things you do most often should be easy to get at, while things which are 7043 and 7044 on that list should be harder to get at. Should we have an item in the `View' menu for `Anonymous FTP Mode', too, just because another browser forces you to click through three windows to get to that? Please, someone explain exactly what this feature does, who it is intended for, how it would improve usability overall, and how it is better than alternative UIs for the same function (e.g. controls in the profile manager, or in the prefs dialog). Otherwise, I really don't think this UI is in a fit state to enter the Mozilla tree.

This is absurd. (I am commenting this as a Mozilla bug, since the this is Bugzilla. The way this is handled in Netscape is none of my business.) * Setting the UI language most certainly does not belong in the View menu, because - The View menu is supposed to contain frequently accessed items and (just like monolingual English-reading Americans) "international users" don't switch the UI language all the time. It is a one-time choice. (I guess from the American point of view, I am one of those strange "international users" with special needs, because I don't live in the U.S. and I am able to read more than one language. Despite all that, I don't feel any kind of need to quickly change the UI language every once in a while.) - In multilingual families, there is normally one common language that all the family members understand at least somewhat. One could argue that the common language might be only spoken and some of the family members couldn't read the language. Even that doesn't warrant cluttering the View menu for everyone, because the family can use the profile feature of Mozilla or the multiuser services provided by the OS. * Regional content selections shouldn't be in the View menu in Mozilla, because Mozilla shouldn't come with any regional content. - The official attitude is that Mozilla isn't for end users. (I might not agree with that, but I'll use the common assertion for the purpose of this bullet point.) The people who use Mozilla are quite capable of choosing their bookmarks themselves. - mozilla.org is coordinating the development of a Web browser. Providing pointers to content is not mozilla.org's business. Due to the point above, providing default bookmarks is virtually of no value. However, what bookmarks get included and what not, has the potential of being a very controversial issue. When the audience doesn't really need default bookmarks, there is no point in including default bookmarks and then having to deal with the complaints. - Even if mozilla.org chooses to include the framework for providing region- specific bookmarks for the convenience of other parties building Mozilla- based products, the UI of Mozilla shouldn't be cluttered in the process-- especially, because even users who travel a lot aren't likely to switch the region pack when they can just access some local portal without making the region pack of their home region disappear. (Yes, I have noticed, there is already a submenu in the View menu, but the fact that the submenu somehow got there doesn't mean it is a good thing that it is there.)

MPT ~ Pls see the attached spec that was prepared by German. Note that it addresses changes to the UI, not only from the menu items, but also from the Prefs dialogue and Profile Manager. IF we can't agree on the View menu items, I do think we are definitely in agreement on the need for the change in Profile Manager, and that the user probably should have the ability to change Language UI and content from within prefs.

Pls review the attached design spec, and lemme know your thoughts. As we have discovered when defining the feature, and utility for the users, there is currently no means for users to recieve addtional packs outside a menu item link from the View Menu (i.e. A x-platform download function in prefs is not supported by the Mac OS). Hence, the need for a Themes "Download More" link form the View menu. Without the ability to download addtional UI packs, the feature is of little use to users who start with the available languages, and wish to use the native language, when the pack is made available. One of the greatest benefits of the Language UI packs, is that a user in China, who currently has the US release, can download Tradiotnal or Simplified Chinese when the pack is made available (i.e. Mozilla users will not have to download and install a full build to use the product in their language). This equates to a 7+ MB download vs. 400K for the Language UI. Is there another way to "Download More" packs or themes other than a menu link?

The proposed spec (images missing, BTW) says about the content pack: "like themes will be multiple per profile, expected to get changed more frequently then themes" Why would there be multiple themes per profile? Why would regional content pack be changed more frequently than themes? Why would regional content packs be a feature of Mozilla (and not only a feature of Netscape 6.x due to marketing requirements)? >there is currently no means for users to recieve addtional packs outside >a menu item link from the View Menu Can't langpacks be downloaded like any other files from www.mozilla.org? >Hence, the need for a Themes "Download More" link form the View menu. Why the View menu? The View menu is not a place for links. The Bookmarks menu is.

From UE perspective, it would be nice if customizations worked in a simlar fashion, so that users don't have to relearn behavior. In short, we need an easy way for users to get to the download page for packs, much like themes.

I (as an L10n contributor) agree that the view menu isn't really the correct place for UI language (and of course not for region) settings, it should be prefs, including the "download more" thingy (yes, I heard wht you told about Mac but I'm speaking from the view of "what would be correct"). Additionally, I think it's good to have it in profile creation, as it currently _is_ a per-profile setting (addressing mpt here). Region packs currently include lots of URLs in Mozilla UI, which could be different in different regions where Mozilla is used (default home page, page of release notes, URL to call on throbber click etc.). I don't remember any real language content in region pack currently. Note that we already have these parts of UI (at profile creation and in "View" menu, not in prefs) for language content.

> From UE perspective, it would be nice if customizations worked in a simlar > fashion, so that users don't have to relearn behavior. In short, we need an easy > way for users to get to the download page for packs, much like themes. So now the theme switcher is used as pretext for adding more settings of the permanent nature to the View menu. :-( The theme switcher is in the View menu mainly to show off the feature. See bug 43546.

The Netscape UI spec for this feature is published at http://www.mozilla.org/projects/ui/communicator/framework/langcontentui/

Now that I see the images of the spec, I think "region" is a misnomer. Where would the contents of the "region" pack be displayed?

I would propose that all Content Packs be under one item, including "region". Open to suggestions though. Q? - It sounds to me, that we may have agreement that Language UI and Content Packs setup should be available from Profile Manager and Prefs. The one contentious area is the menu items under View. Is this correct?

Comments on the UI spec: - Instead of a cascading menu entry "Apply Content Pack >", why don't we just have a "Apply Content Pack..." which opens the pref dialog to Content Pack panel? If we do this, maybe the menu entry should be under the Edit (not View) menu similar to "Preferences..." (The same suggestions apply to "Apply Theme >".) - In the pref dialog panel, why does the apply button need to include the name of the content pack (e.g., "Apply San Diego Regional")? Since the pack is already highlighted, it seems "Apply" is sufficient. And if the content pack has a really long name, then we'll end up with a really wide button. Addtionally, any time you piece together phrases, you create localization problems because word ordering is language dependent.

> Now that I see the images of the spec, I think "region" is a misnomer. I agree. What has really been separated is UI v. content (not language v. region). Both UI and content may be language and/or regional dependent. Someone may want English UI for British or American regions (e.g., "-or" v. "-our", "-ize" v. "-ise"), or Swiss content in the French or German language.

sounds like we're still talking about the design of this feature, i.e. we stil haven't agreed on whether this is the right thing to do for mozilla. I don't think my team can fix this. i18n group will have to find some other resources or make it netscape only. I'm moving this bug to Future.

Thankyou for posting that document, German. I wouldn't call it a `spec', since it doesn't answer any of the basic questions I think a spec should cover (what the feature *does*, who would use it, why they would use it, why alternative designs were rejected, etc); but those questions have been answered to some extent by others in this bug. It's now quite clear that there a `Set Language' item in the `View' menu would be more confusing and cluttersome than useful, since Mozilla users do not need to change their UI language nearly often enough for the feature to deserve a menu item. UI for this in the profile manager (bug 65253) would be quite sufficient. And for downloading new language packs, every Mozilla user should be able to do that on the same page on mozilla.org from which they downloaded Mozilla in the first place -- or via a default bookmark pointing to the download page, for those users who have installed Mozilla as part of their Debian, Red Hat, or other GNU/Linux distribution. As for `content packs', they may be of use to users of Netscape's commercial distribution, though obviously you've still got a long way to go before you come up with a UI which is close to being understandable. (From German's mockup: `Friendly explanatory text that goes to great effort to explain what a content packs is' ... I think that sums up the problem quite nicely.) But as Henri so thoroughly pointed out, content packs are of no use to users of Mozilla, who are quite capable of setting up their own bookmarks themselves, and who indeed may be queasy about mozilla.org offering default bookmarks at all. Nor, I think it's fair to say, would they be of use to the vast majority of Mozilla distributors, most of whom will be too small to have the resources to organize multiple content packs for different regions. Therefore, as owner of the `User Interface Design' component where this bug currently sits, I'm moving this bug to the `Derivatives' > `Netscape 6' component. I'd like to thank those people at Netscape who worked on the back end to separate language settings from content settings; this means that language settings (which are useful for Mozilla users) can be part of the Mozilla code, while content settings (which are not useful for Mozilla users) can be made Netscape-only. Moving to `Netscape 6' component. Any appearance of `content packs', or any introduction of language-/region-related items in the `View' menu, in the Mozilla trunk will be treated as a usability regression.

> content packs are of no use to users of > Mozilla, who are quite capable of setting up their own bookmarks themselves, > and who indeed may be queasy about mozilla.org offering default bookmarks at > all. Mozilla already includes bookmarks under "Personal Toolbar Folder" and "Mozilla Project". It is useful and productive to provide a standard set of bookmarks to facilitate project testing and feedback as well as providing overall project info. Additionally Mozilla adds/configures: - Tinderbox sidebar entries - URLs under the Help, Debug and QA menus - search engines - home page A given Mozilla project or a group of developers may want different content. For example, I believe the Mozilla Japan folks have their own bug system which they use to log bugs using Japanese. Groups of developers working on Mozilla ports or derivatives may want a different Tinderbox in the sidebar, or a different bug/feedback form, or different Debug/QA tools. The notion of "content packs" is valuable to Mozilla as well as for commercial usage. Whether or not anything should be exposed in the View menu is a separate issue.

bobj - please tell me if you want me to move this bug to Bugscape. Thanks. It is not going to do well on my plate.

lchiang> bobj - please tell me if you want me to move this bug to Bugscape. lchiang> Thanks. It is not going to do well on my plate. Note German's UI spec removes UI switching from the menu and makes it only available via prefs of profile manager, so I updated the summary from from "View" menu: Need to add "Set Language" and "Set Region" to "View" menu: Add "Apply Content Pack" For now, reassigned to jaimejr. If we agree to a fix, I'll find a real owner. My 2 cents (or am I up to 8 cents now): I don't believe this is an issue of a Mozilla v. Netscape feature. This should be WONTFIX or remain open in bugzilla (under Browser not Derivatives). I believe content packs are useful (see previous comment), and the issue is whether it belongs in a top level menu or only accessible in prefs and the profile manager. (If this gets marked WONTFIX, and Netscape still wants the menu entry, then a new bug should be opened in bugscape.) I agree in principle that menu entries should be reserved for frequently used operations. On the other hand, this principle does not seem to be evenly applied to our current menus. We seem to also include things there that we think are useful, but not easily discoverable (e.g., View|Apply Theme, View|Use Stylesheet, View|My Sidebar Search Tab|Basic/Advanced) Practically, I think "Apply Content" could more useful than "Apply Theme" for most users. I think we need to hear mpt's response to my comments.

I would priotize dealing with releated Profile Manager and Prefs bug, first. I 100% in agreement with Bob's comments, and I am even willing to agree on not having menu items under view. WFM, if . . . However, I still beliew all browser customizations, such as View | Apply Theme, should be consistent in their behavior. And, still have the requirement for an easy, and consistent way (ala Themes) to download addtional packs. We should not have one-offs for a user to download and customize the browser.

> Practically, I think "Apply Content" could more useful than "Apply Theme" for > most users. As I said in my 2001-05-15 comment, and Henri suggested in his 2001-05-15 comment, you shouldn't use the uselessness of `Apply Theme' as a precedent for including the (arguably) slightly less useless `Apply Content Pack'. `Apply Theme' shouldn't be in the menus either. > Mozilla already includes bookmarks under "Personal Toolbar Folder" and > "Mozilla Project". It is useful and productive to provide a standard set of > bookmarks to facilitate project testing and feedback as well as providing > overall project info. That is not a feature, it is a bug. It is a temporary workaround for the appalling state of the mozilla.org Web site -- such that you can't find these links (and bookmark the ones *you* are interested in) within a few clicks from the default home page. Once the mozilla.org site is fixed, I expect the number of default bookmarks in Mozilla to approach zero. > The notion of "content packs" is valuable to Mozilla as well as for > commercial usage. It looks as if you're trying to invent uses for content packs after the fact. All the examples you gave are of single links or panels -- there is no obvious group which would have a large intersection in a large number of bookmarks and/or sidebar panels they would be interested in, such that it would be more intuitive for those people to switch to these bookmarks or sidebar panels as a set rather than adding the individual bookmarks or panels which they are interested in. I strongly suspect the same will be true for Netscape users, too; but that's a problem for Netscape to deal with.

Per Vishy's request, setting priority P1, so that we can triage with Nav for M0.9.2. Marking as RTM, and nsCatFood.

adding URL to German's spec

Build ID: 2001060409 This is happening on a German Build with the Build ID: 2001060409. It occurs when I submit a Form (ex. Submitting comments in Bugscape by cliking on the "Commit" button or keying enter.

oooooops . . . pls ignore my last statement. This was meant for another bug. :-(

Adding PDT+ per the Friday afternoon PDT meeting.

Jaime, are you going to reassign this?

Reassigning to Ftang. Suggest we use the single menu item (View | Set Language/Region), change the word Word "Region" to "Content", so it matches the Prefs implementation for this feature. Addtionally, the new drop-down, should look as follows . . . Download More <------------> Apply Language > US English > French > (build, to accept download packs) <------------> Apply Content > United States Region > France Region > (build, to accept download packs)

Adding rudman and hangas to cc: list. Any ideas here guys?

Well my idea is to not even have these menu items and just support these features from the prefs. It seems to me that the number of users that would need to change these settings every day are very few. Adding a menu item to make a feature more discoverable is not in my opinion a good idea. Too many menu items make every menu item less discoverable. I think we have too many menu items in mozilla already. Maybe in the future there can be a way to turn on features like this for folks that do need to change these settings every day, for now I think we should target the majority of our users.

Hangas - I would agree with your statements on moving this stuff to Prefs. In fact, the ability to switch the packs in Prefs is already available. However, we are not allowed to put a "Download" button in Prefs because we can't have multiple Modals dialogues up at one time. Hence, the need for the menu item as it is, to support the Download of more packs. Addtionally, it is consitent with 6.0 behavior. Any other ideas?

So are you saying that because one menu item is needed that all of them need to be there?

Actually, I'm looking for suggestions right now. It would be nice to be consistent with how Theme customization works, and for language switching might actually be userd more. Any ideas?

Default bookmarks perhaps?

Jaime, what about instead of three menu items (or correctly submenus) about locale, content pack and theme if we change it to one menu item (submenu) called "Download UI" (or similar) with Items for "New UI Language", "New Content Pack" and "New Theme"? This would decrease menu items in view menu (which is the most overloaded one already), keep the download feature and get rid of chrome switching from the menu. This should and can be done via prefs (existing profile) or profile manager (locale/content for new profile).

No objection to Robert Kaiser's idea. I don't think I should own the UI work.

I object, View>Download>Foopy makes no sense to me. If you're going to change its functionality then I suggest you try to find a correct place to stick this nightmare. Help>Software Updates used to exist, and can probably be resurrected. We could put it there.

I prefer Robert Kaiser's idea, since it concentrates all UI Customizations under one umbrella for consistent usability. Addtionally, there is "NO" HELP | Download menu item now, and I much rather consolidate items into logical system, then create new ones. Vishy - FTang does not feel he should own this one, and we are come up to M0.9.2 deadline, or part it. I'd be agreeable to removing the seprator, and just having the Download More option for this round. In hopes, that we can improve usability in M0.9.3 or just a little bit later. My immediate need right now is provide users with the ability to download MORE packs. What do you think?

Jaime - We already have Download More in the UI today. Are you saying that that is sufficient? Sorry - I could not understand all the comments in the bug.

All I am saying, is that it could work for that way for M0.9.2, but we need to work on suability for M0.9.3 and later (i.e. Keep "Download More", remove everything else for this round). Just a suggestion, so we can move on . . .

I sure hope we track how many downloads we get of content packs in 6.1, so we can prove that this isn't needed, and it can be taken out. This is an excellent example of bloat at it's finest.

here's a suggestion via mike kaply by way of timeless . . . ------- Additional Comments From timeless@mac.com 2001-06-06 12:10 ------- Henri Sivonen, did you read mkaply's comments (2001-06-05 12:31)? . . . The fact that we can't open a web browser from the preference dialog because it's modal is a problem. Microsoft has a solution which is to prompt the user for permission to close the dialog and open the next window (dialog in their case, but whatever). I would be amaiable to this solution, if: 1) Everyone agrees this is the best way to go, and we are done; 2) We got help with the code (timeless is this something you can do?); 3) Recieved expedient reviews and the check in occurs ASAP. Vishy/Ftang - Any addtional thoughts? I think this would be solution, IF it is doable. Alternatively, I would default to my other proposals.

I like this solution that timeless suggests. We could use that for other buttons inside of prefs as well. Do you have the exact wording on that dialog? I can probably get some help to create this if needed.

HOUSTON...WE MAY HAVE A SOLUTION. Ok, looks like we got some agreement here from the Netscape house (UI and PM), plus a volunteer to take a look at this over the weekend (i think?). Vishy/Ftang - Unless either of you adamantly disagree, I think Hangas and I think this could work . . .

I like this solution - prompting the user and closing the prefs dialog, since it is known UI design i.e. IE does it and it seems to be a reusable pattern (Commercial could use this same pattern in the Smart Browsing panel > More Information button which brings up a web page and causes some weird behaviour). Lets not get our expectations unrealistic about - having the code in a hurry (to do this before 6/26 requires drivers approval as drivers controls the branch until next week at least and this is unlikely to get deemed "critical for m0.9.2"). - expedient reviews. This will have to go through normal review and super-review process and the turnaround can be non-predictable sometimes. However - for Netscape purposes we will need a L10N exception to do this if it is not in the tree by 6/26 (at least the strings) so it would be good to start on this. I'll email mcarlson about the exception.

Thanks Vishy! Do you or anyone know, a way we could get an expedient "ok to proceed" from drivers (e.g. I am assuming drivers are the same people reviewing . . . lemme know if this is not the case). It sounds like a lot of people commenting int the bug like this solution in both the Mozilla community, and Netscape. I would think this would be something we'd like to do ASAP to resolve this one and move on to other things.

Jaime - none that I'm aware of. I think drivers will want to see the patch and I've not heard of drivers pre-approval. The question will also arise about the relevance of this patch to mozilla for mozilla0.9.2. The best bet is to work on implementation, then r,sr then assess where we are. We may already be branched by then and not need drivers approval if m0.9.2 is out the door.

Vishy - OK, I think there is a Mozilla contributor working on this one, but not 100% sure. And, I don't think Ftang wants to get into this one. Any ideas on how to get the patch work done? IS this something we need for other modals in the Prefs panel? I don't manage a dev team, so I am leaving this one to you, Bobj and Ftang to resolve, if we don not get external help.

Reassigning to vishy; vishy, do you know who is working on this bug? It seems that we need to get it at least on a limbo build if we cannot make it by 6/26. Please, update the bug with comments on when it can be done.

Ben - could you take this. the summary is inaccurate, can you read the bug and update the summary to the right value. we shd target this to the first limbo build (by the end of this week.

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 we get a patch in for this on Thursday since it would be good to have the Friday build be the first candidate. thanks, Vishy

matt says 'r=matt' and blake says 'sr=blake' they both express general disappointment in the modal change, but I think it's peachy keen!

msanz - this involves adding another string. is this ok

Ben - it is okay for this string change as it is a PDT+ bug. Please check this into the mozilla trunk and branch today. Please send an email to msanz with the bug number, mentioning the l10n impact. thanks! Vishy

we should get this baby into the branch if it's ready.

Jatin, fyi, for possible doc impact.

Ben: Your last patch (resources/content/pref-contentpacks.xul,etc) looks more like patches for bug 65251:'Need to add "Language" and "Regional Content" to Appearance in Preferences...'

Ben, Will your patch for this bug add "Download More" and "Apply" buttons to the Content Packs panel in Prefs? Also, I see in the 07-05-06-trunk build that the title for this panel is blank; will the patch fix that as well? I will attach a screenshot in case it is unclear what I'm referring to.

yes, we need the feature in. Please check in asap, preferably before 7/6

Button checked in. Marking FIXED.

Docs - please note that this makes the pref panel be non-modal now.

Switching QA contact to jonrubin for bug verification.

Reopening - Did not see "Apply Content Pack" in View menu on 07-06-06-trunk (tested on WinMe-Ja). Ben: Could you please answer my question from 07/05 about whether your patch will apply to the Prefs UI as well? Thanks.

I think the Summary was misleading. After discussion the summary of the bug is "add Content Pack panel to preferences, with a download more button". That is what is checked in.

marking fixed per new summary. please verify. oh wait - you will have to wait till the preferences smoketest blocker is cleared.

i've verified bug 89600 as fixed. some observations: on linux [2001.07.06.12-branch comm], the category tree has a blank space for Content Packs, and the button in the panel is blank. on mac [2001.07.06.12-branch comm], Content Packs isn't in the prefs dialog at all. unable to currently check win98, as i'm booted up in linux [could someone else pls check?]. interestingly, linux trunk mozilla build from 20:15ish last night, Content Packs *is* listed in the category tree. [no button in panel, but that's a recently added feature, eh?]

see bug 89725 for a patch that fixes the blank menuitem in prefs & the blank button. the patch will need to be applied to both the trunk & branch.

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.

Jaime, please note that you originally filed this bug to add "Apply Content Pack" to the View menu. With the new summary added on 07/06, it is now essentially a dupe of bug 65251.

From various comments in this bug (mpt and others), I'm missing one important thing in the fixes to this bug: I thought it was agreed that the view menu items for "Languages and Web Content" as well as "Apply Theme" should go away. At least the first of those two should be addressed here, the second may get a different bug and resolved on its own way - but it should bet away as well! This will also make other bugs e.g. bug 66909 obsolete...

Please open the remaining issues with this bug as new bugs (its way too confusing to wade through this long discussion). Also we need to assess the PDT+ nature of the new bugs not just inherit that into the remaining issues with this bug.

Vishy - 65251 was the bug dealing with Prefs issues for the packs. This bug was opened to deal the View | Menu. Now that the Prefs dialogue seem to support Download, I would be amiable to close this one, and reopen the bug to hide/move (debug) this menu item; so long as Prefs functions correctly and supports all platforms. At a minimum, View | Set Language/Region is no longer applicable, since we call the packs "Language" and "Region" packs.

Now that the functionality requested (ability to download more content packs from preferences dialog) is present, can someone verify this bug fixed?

This functionality has already been verified on Win and Linux; it cannot be verified on Mac because the Content Packs panel was not found in Prefs.

Need to Reopen. This has not been fixed in Mac.

It turns out that fixing bug 90002 will not fix this on the Mac (the patch in 90002 was already on the branch). There is something deeper going on here - I'll have to talk to Pchen tomorrow to track it down.

Taking from Vishy since we've fixed this on my powerbook.

As is usual for stuff not showing up only on the mac, need to add mozilla/ extensions/content-packs/resources/jar.mn to the mac build list

r=vishy (I saw this working). Blake could you sr= this?

Hold on, oops. sr=ben@netscape.com for the branch ONLY. This line is un-necessary for the trunk given the same line several lines up. The reason this wasn't getting built was that I forgot to set content_packs to 1 in MozillaBuildFlags.txt when initially checking this in. This is the correct fix for the trunk as it allows people to disable this UI. A patch to do this is attached to 65251 and is what should land on the trunk, I think.

Just IM'd with Ben some, and we agree that the fix he attached to 65251 is the correct way to fix this.

I've just checked in on the branch. I leave it up to Ben to check in on the trunk. Marking this bug fixed.

Umm, no, really, marking FIXED. ;-) Sorry for the spam

As I didn't see anyone mention a seperate bug about removing the menu items from "View" menu, i filed bug 90304 for this problem.

Reopening - Still cannot see Content Packs panel on Mac trunk build as of 07-12-08-trunk-comm.

I think we're saying that the branch build is fine but the trunk build is broken. REmoving PDT+ designation in that case. Ben/paul - please fix the trunk build when possible,

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).

Assuming Ben intended to mark this as fixed based on fixing bug 65251.

Verified on 07-16-04-trunk on MacOS9.1.