65241 - Prefs: add Content pack panel with Download button.

Status: VERIFIED FIXED

(SeaMonkey :: Preferences, defect, P1)

Description

[Jaime Rodriguez, Jr.]

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

Comment 1

[Jaime Rodriguez, Jr.]

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.

Comment 2

[Jaime Rodriguez, Jr.]

------- Additional Comments From [e-mail] 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 [e-mail] 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 [e-mail] 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 [e-mail] 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...

Comment 3

[german]

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.

Comment 4

[tao]

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

Comment 5

[Jaime Rodriguez, Jr.]

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.

Comment 6

[german]

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. 

Comment 7

[Jaime Rodriguez, Jr.]

Reassigning to German for UI specification.

Comment 8

[msanz]

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

Comment 9

[Matthew T (active 1999-2002)]

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.

Comment 10

[hangas]

Triage Team marking nsbeta1+ and 0.9

Comment 11

[Zach Lipton [:zach]]

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

Comment 12

[Jaime Rodriguez, Jr.]

Adding Andreas to cc: list.

Comment 13

[Andreas Becker]

Adding Yuying to cc: list.

Comment 14

[hangas]

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

Comment 15

[Jaime Rodriguez, Jr.]

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?

Comment 16

[Jaime Rodriguez, Jr.]

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.

Comment 17

[Jaime Rodriguez, Jr.]

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.

Comment 18

[Viswanath Ramachandran]

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

Comment 19

[Asa Dotzler [:asa]]

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. 

Comment 20

[Jaime Rodriguez, Jr.]

reassigning to nhotta for review.

Comment 21

[Jaime Rodriguez, Jr.]

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.

Comment 22

[Asa Dotzler [:asa]]

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. 

Comment 23

[Jaime Rodriguez, Jr.]

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.

Comment 24

[Asa Dotzler [:asa]]

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.  

Comment 25

[Jon Rubin]

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.

Comment 26

[Asa Dotzler [:asa]]

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.  

Comment 27

[nhottanscp]

Reassign to vishy.

Comment 28

[Matthew T (active 1999-2002)]

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.

Comment 29

[Henri Sivonen (:hsivonen)]

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

Comment 30

[Jaime Rodriguez, Jr.]

Attachment: Language UI and Content Setup

Comment 31

[Jaime Rodriguez, Jr.]

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.

Comment 32

[Jaime Rodriguez, Jr.]

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? 

Comment 33

[Henri Sivonen (:hsivonen)]

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.

Comment 34

[Jaime Rodriguez, Jr.]

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.

Comment 35

[Robert Kaiser]

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.

Comment 36

[Henri Sivonen (:hsivonen)]

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

Comment 37

[german]

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

Comment 38

[Henri Sivonen (:hsivonen)]

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?

Comment 39

[Jaime Rodriguez, Jr.]

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?

Comment 40

[bobj]

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.

Comment 41

[bobj]

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

Comment 42

[Viswanath Ramachandran]

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. 

Comment 43

[Matthew T (active 1999-2002)]

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.

Comment 44

[bobj]

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

Comment 45

[lchiang]

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.

Comment 46

[bobj]

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.

Comment 47

[Jaime Rodriguez, Jr.]

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.

Comment 48

[Matthew T (active 1999-2002)]

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

Comment 49

[Jaime Rodriguez, Jr.]

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

Marking as RTM, and nsCatFood.

Comment 50

[[e-mail] (away - not reading bugmail)]

adding URL to German's spec

Comment 51

[Jaime Rodriguez, Jr.]

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. 

Comment 52

[Jaime Rodriguez, Jr.]

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

Comment 53

[Jaime Rodriguez, Jr.]

Adding PDT+ per the Friday afternoon PDT meeting.

Comment 54

[Viswanath Ramachandran]

Jaime, are you going to reassign this? 

Comment 55

[Jaime Rodriguez, Jr.]

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)

Comment 56

[Jaime Rodriguez, Jr.]

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

Comment 57

[hangas]

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.

Comment 58

[Jaime Rodriguez, Jr.]

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?

Comment 59

[hangas]

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

Comment 60

[Jaime Rodriguez, Jr.]

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?

Comment 61

[Henri Sivonen (:hsivonen)]

Default bookmarks perhaps?

Comment 62

[Robert Kaiser]

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

Comment 63

[Frank Tang]

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

Comment 64

[timeless]

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.

Comment 65

[Jaime Rodriguez, Jr.]

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?

Comment 66

[Viswanath Ramachandran]

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. 

Comment 67

[Jaime Rodriguez, Jr.]

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

Comment 68

[Jason Kersey]

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.

Comment 69

[Jaime Rodriguez, Jr.]

here's a suggestion via mike kaply by way of timeless . . .

------- Additional Comments From [e-mail] 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. 

Comment 70

[hangas]

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.

Comment 71

[Jaime Rodriguez, Jr.]

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

Comment 72

[Viswanath Ramachandran]

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. 

Comment 73

[Jaime Rodriguez, Jr.]

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.

Comment 74

[Viswanath Ramachandran]

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. 

Comment 75

[Jaime Rodriguez, Jr.]

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.

Comment 76

[msanz]

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.

Comment 77

[Viswanath Ramachandran]

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.  

Comment 78

[Marek Z. Jeziorek]

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.

Comment 79

[Viswanath Ramachandran]

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

Comment 80

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: patch to implement download more button.

Comment 81

[Ben Goodger (use ben at mozilla dot org for email)]

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!

Comment 82

[Ben Goodger (use ben at mozilla dot org for email)]

msanz - 

this involves adding another string. is this ok

Comment 83

[Viswanath Ramachandran]

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

Comment 84

[chris hofmann]

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

Comment 85

[rudman]

Jatin, fyi, for possible doc impact.

Comment 86

[tao]

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

Comment 87

[Jon Rubin]

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.

Comment 88

[Jon Rubin]

Attachment: Prefs screenshot as of 07-05-06 trunk

Comment 89

[msanz]

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

Comment 90

[Ben Goodger (use ben at mozilla dot org for email)]

Button checked in. Marking FIXED.

Comment 91

[Viswanath Ramachandran]

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

Comment 92

[Andreas Becker]

Switching QA contact to jonrubin for bug verification.

Comment 93

[Jon Rubin]

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.

Comment 94

[Viswanath Ramachandran]

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. 

Comment 95

[Viswanath Ramachandran]

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

Comment 96

[sairuh (rarely reading bugmail)]

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?]

Comment 97

[Stephen Walker]

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.

Comment 98

[Jon Rubin]

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.  

Comment 99

[Jon Rubin]

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.

Comment 100

[Robert Kaiser]

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

Comment 101

[Viswanath Ramachandran]

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. 

Comment 102

[Jaime Rodriguez, Jr.]

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.

Comment 103

[Ben Goodger (use ben at mozilla dot org for email)]

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

Comment 104

[Jon Rubin]

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.

Comment 105

[Jaime Rodriguez, Jr.]

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

Comment 106

[Viswanath Ramachandran]

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. 

Comment 107

[Paul Chen]

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

Comment 108

[Paul Chen]

Attachment: need to run over content-packs jar.mn file in mac build list

Comment 109

[Paul Chen]

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

Comment 110

[Viswanath Ramachandran]

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

Comment 111

[Ben Goodger (use ben at mozilla dot org for email)]

sr=[e-mail]

Comment 112

[Ben Goodger (use ben at mozilla dot org for email)]

Hold on, oops. 

sr=[e-mail] 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. 

Comment 113

[Paul Chen]

Attachment: Ben's fix from 65251

Comment 114

[Paul Chen]

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

Comment 115

[Paul Chen]

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

Comment 116

[Paul Chen]

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

Comment 117

[Robert Kaiser]

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.

Comment 118

[Jon Rubin]

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

Comment 119

[Viswanath Ramachandran]

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, 

Comment 120

[Jon Rubin]

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

Comment 121

[Jon Rubin]

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

Comment 122

[Jon Rubin]

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