Closed Bug 61162 Opened 24 years ago Closed 23 years ago

Move `Set Language/Region'/`Languages and Web Content' submenu to Debug

Categories

(SeaMonkey :: General, defect, P3)

Product:
SeaMonkey
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME
Milestone:
Future

People

(Reporter: mpt, Assigned: ftang)

References

Details

(Keywords: intl)

Attachments

(3 files)

Remove Languages and Web Content menu + associated resources
3.71 KB, patch
Details | Diff | Splinter Review
Patch v.2 - move to Debug menu
6.77 KB, patch
Details | Diff | Splinter Review
Slightly fixed patch - move out-of-place property
7.90 KB, patch
Details | Diff | Splinter Review
Build: 2000112320, Mac OS 9.0 To reproduce: * Change the language used for UI text in Mozilla. What happens: * You go the the `View' menu and choose an item from a submenu which is obfuscatingly named `Languages and Web Content', even though it doesn't apply to Web `content'. What should happen: * You go to a `Languages' subcategory of the `Appearance' category of prefs, and add/remove/choose UI languages there. Switching between languages for Mozilla's user interface will be done nowhere *near* often enough for it to deserve its own submenu. At most, it will be switched once or twice in the lifetime of a user profile. So it doesn't belong in the menus.
> What happens: > * You go the the `View' menu and choose an item from a submenu which is > obfuscatingly named `Languages and Web Content', even though it doesn't apply > to Web `content'. This menuitem refers to UI language and regional contents (links/URLs) associated w/ menuitem such as Home, Search, etc. See this document for related terms: http://www.mozilla.org/projects/l10n/mlp_regional.html. >What should happen: >* You go to a `Languages' subcategory of the `Appearance' category of prefs, > and add/remove/choose UI languages there. This is one of the places users can switch languages and regional links.
'Web' content is still the wrong term as i wrote in one of mpt's nightmare bugs, I also suggested what seems to be the correct term. Content in chrome is not Web content.
Adding nsbeta1, moz1.0.
Status: NEW → ASSIGNED
Keywords: nsbeta1
Target Milestone: --- → mozilla1.0
nav triage team: A mac build from today still shows "Languages and Web Content", whereas a 2001040604 win32 build shows "Set Language/Region"
Assignee: ben → pchen
Status: ASSIGNED → NEW
Keywords: nsbeta1 → nsbeta1+
Hardware: All → Macintosh
If the submenu still exists at all, it's still silly, no matter what it's called.
Hardware: Macintosh → All
Summary: `Languages and Web Content' submenu is silly → `Set Language/Region'/`Languages and Web Content' submenu is silly
Paul, I can get this for .9.1. It's real simple. If you really want it, feel free to take it back.
Target Milestone: mozilla1.0 → mozilla0.9.1
as discussed in team meeting, moving all Nav+ team members nsbeta1+ P3 bugs from mozilla0.9.1 to mozilla0.9.2.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Here's a patch. And could the person who sr=ed and approved the placing of the selectLocale() JS function in "strres.js" please step forward and explain? ;-) Gerv
OK, mpt wants this moved to the Debug menu, because it's useful for testers. Given that I doubt anyone cares very much about the aesthetics of that menu, I've just added it to the bottom. I also took the opportunity to change the name to something more sensible. New patch coming right up. Gerv
Assignee: pchen → gervase.markham
Keywords: mozilla0.9.1
Summary: `Set Language/Region'/`Languages and Web Content' submenu is silly → Move `Set Language/Region'/`Languages and Web Content' submenu to Debug
Target Milestone: mozilla0.9.2 → mozilla0.9.1
blake: just a ping :-) On IRC you said you'd review this. Gerv
Keywords: patch, review
r=doron, cc: alecf for possible sr=
sr=alecf for the quality of the content, but you MUST get a reviewer from i18n for my sr= to be valid. I want to make sure we have buy-in from the module owners.. tao? ftang?
CCing ftang for a possible review... However, IMO this is a UI Design issue, not an i18n issue. If the UI designers decide this feature is not important enough to merit space in their UI, and that the current UI exposure in the Profile Manager is sufficient (and they have come to this conclusion), then they should have the last word. Gerv
Is there a View Menu spec yet? Who owns the UI design, here, if not mpt? The intl module owners (or any other code module owners) don't get to make up high profile UI without broader buy-in, if not a real spec, I think. /be
I cannot find any other way to use this feature other than this menu - no prefs, no nothing. if we move it to the debug menu, then release builds will essentially hide the existence of this feature, and that doesn't seem right either. mpt mentions that this option should appear in the preferences, but I can't find it anywhere. If i18n doesn't respond, I think we at least need to put this in preference somewhere so this feature is actually accessable from a non-debug build.
doh! tao is on sabbatical, cc'ing ftang and nhotta who might know more
Alecf: There is a (hard-to-understand) UI at profile creation time. The idea is to add a UI for language switching to the prefs.
well, I don't want to see this patch land until we have a UI in the prefs then. Is there a bug for that? let's set up a dependancy
There are bugs for the UI issues, please look at. bug 65241 - View" menu: Add "Apply Content Pack bug 65251 - Need to add "Language" and "Regional Content" to Appearance in Preferences bug 65253 - Profile Creation: Need a user interface for Regional Content
Depends on: 65251
> bug 65241 - View" menu: Add "Apply Content Pack For heavens sake, no! :-) mpt hates this idea too. > bug 65253 - Profile Creation: Need a user interface for Regional Content As far as I can tell (and no-one has explained it yet in any of these bugs) all this "Regional Content" stuff is a Netscape-only feature and has no place in the Mozilla tree. Gerv
Gerv, I just posted some pointers to Tao's backend work in bug 65253. While it certainly can be argued that the presence of "Apply Theme" on the "View" menu should not serve as a precedence for similar features, I don't see anything evil in the language and browser content (read links, bookmarks, channels). While I can't speak for Netscape as a business entity, it is certainly conceivable that they might want to roll commercial links into the content packs. Separation of the Browser language and content is a good thing and I don't quite get the almost militant attitude in fighting them. The separation means that it'll be much easier to come up with content packs, since they'll be lightweight and that increases customizability. Please remember that customizability is a universal and potentially quite useful, to me it doesn't necessarily infer evil commercial interest. I'd side here with bobj - if I recommended a friend Mozilla as their primary browser, they might not appreciate Tinderbox, Bonsai, Bugzilla and their assorted friends sticking in their face on an everyday basis.
Juraj, The reason for the slightly combative attitude, for which I apologise, is that I cannot understand why, despite long-standing objections from the 3 people who design and define Mozilla's UI, the i18n team _persist_ in attempting to place UI in Mozilla (in particular, in the View menu) which the UI team do not wish to be there. The fact that i18n are attempting to keep this feature and add others without a proper spec (which mpt has requested, in other bugs, on several occasions) outlining what it does, who would use it and what it's good for, also gets me very annoyed. Mozilla is not Netscape. You, I, mpt, and the rest of your i18n team are all contributors to the Mozilla project. You may do what you like in your commercial tree, as any Mozilla contributor can, but assuming that this carte blanche extends to Mozilla is both wrong and rude. I would add, in passing, that the UI that this bug is trying to remove was produced and checked in last year in a Netscape-confidential bug with no consultation and not a reviewer in sight. Not only did they place a random entity for an alert box in brand.properties (brand.properties! A file which contains two other entities, both of which are "Mozilla", and obviously related to branding) but they put the code to run it in strres.js (a file whose other code relates to string bundles). This thing is a UI mess, a design mess and a coding mess. It should be backed out now and done right according to the Mozilla process. Gerv
> As far as I can tell (and no-one has explained it yet in > any of these bugs) all > this "Regional Content" stuff is a Netscape-only It is not. This has been discussed in the newgroup (where I understand bug discussions should be done). The regional content contain: * Bookmarks * Translation of MIME type descriptions * Sidebar panels + translated names of sidebar panels (e.g. 'Seach' --> 'Søk' in Norwegian) * Search engine plugins (both new ones, for locale-specific search engines, but also translations of the names and descriptions of the search engines) * URLs and their names/titles (e.g. the 'Go to Bugzilla' link and the Mozilla Mail start page (which may be localized)) * Some localizable preferences (e.g. the default character encoding for e-mail and Web pages) * ... possibly other things -- see the l10n Web page
> * Translation of MIME type descriptions Isn't that a bug? Why would the translations not belong in a langpack? > * Sidebar panels + translated names of sidebar panels > (e.g. 'Seach' --> 'Søk' in Norwegian) Isn't that a bug, too? Why don't the translated string of panels that are considered part of the UI (Search, Bookmarks) be part of a langpack? > * URLs and their names/titles (e.g. the 'Go to Bugzilla' link and The taskbar is no more.
>> * Translation of MIME type descriptions > > Isn't that a bug? Why would the translations not belong in a langpack? I don't know. Possibly because you can add other MIME types? >> * Sidebar panels + translated names of sidebar panels >> (e.g. 'Seach' --> 'Søk' in Norwegian) > > Isn't that a bug, too? Why don't the translated string of > panels that are > considered part of the UI (Search, Bookmarks) be part of > a langpack? Yes! I opened bug #52930 regarding this 2000-09-16. It's very easy to fix, but hasn't be fixed yet. >> * URLs and their names/titles (e.g. the 'Go to Bugzilla' link and > > The taskbar is no more. The URLs also work for the throbber and the help menu.
Gerv: can you work with whoever is willing to help at netscape.com to get the bad stuff fixed, or moved to the ns tree? I know, it's not your responsibility to do the latter. We could just say "enough" and remove the offending code from the cvs.mozilla.org tree. But I hope that some @netscape.com actually agree, and will help. If no one does agree and help, then we'll have to set a generous deadline for removal, notify frequently, and finally do the deed. /be
Well, I can't help very much with moving it to the NS tree, obviously. I can move it to the QA menu, though ;-) Seriously, if Netscape wish to persist with this UI aberration, they will need to move it to the Commercial tree before, say, the tree opens for 0.9.3. I am happy to help in any way I can with this, if requested. If it still hasn't moved by then, it goes -> QA. Reassigning to Juraj so he can give this problem to the correct person. Gerv
Assignee: gervase.markham → jbetak
Jaimie, it looks like we are not going to get the new view menu entry "Set Language/Region" in Mozilla. Moreover, it seems that the existing entry "Set Languages and Web Content" will be moved into the QA/Debug menu. In the light of this, I would suggest rewording Bugscape bug 4940 http://bugscape.netscape.com/show_bug.cgi?id=4940 to reflect the need of not only one, but two view menu entries in the commercial tree. I'll try to land it for 0.9.1, although it looks bleak given the usual review lag.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Please go to mozilla l10n newsgroup and discuss about language/region issues.
Juraj: The current menu isn't going to move anywhere until after the 0.9.1 branch, so you won't have the effort of implementing the second one as a commercial-only thing. Gerv
Gerv, thanks for following up on this. Targeting the fix for 0.9.2 sounds great, since 9.1 seems to be pretty unrealistic at this point...
Status: NEW → ASSIGNED
I do not agree the move to QA menu.
Adding jbetak to cc: list.
Just to summarise, then: the ball here is currently in Netscape's court to transplant this menu into the Commercial tree. Given that 0.9.2 is now "special", and happening unusually soon, you may not get to this until after 0.9.2 - fair enough. But if it gets towards 0.9.3 and nothing has yet happened, this gets menu will be removed from Mozilla. Hope that's OK :-) Gerv
It is not ok.
According to http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser Internationalization Internationalization is the process of designing and developing a software product to function in multiple locales. This process involves identifying the locales that must be supported, designing features which support those locales, and writing the code needed and XP Apps: GUI Features For problems with cross-platform applications that have a graphical interface. Make sure it doesn't fit into another, more applicable component before you file it here. Examples: View Page Source or Page Info doesn't work. Open Web Location dialog doesn't work. Find in This Page doesn't work. File Open (file picker) doesn't work. Problems with the dialogs associated with downloading/saving files. this bug is currently mark Component as "XP Apps: GUI Features" , but since it does not fit "Make sure it doesn't fit into another, more applicable component", change the component to "Internationalization"
Component: XP Apps: GUI Features → Internationalization
You're right - we should make sure this bug is in the right place. I actually think it fits better here: User Interface Design: "For usability issues in Mozilla's User Interface design. ... this is where to raise specific issues and concerns regarding the quality of Mozilla's user interface design,..." IMHO, the code needed to support multiple locales is already written. This is a UI issue. Gerv
Component: Internationalization → User Interface Design
OK, it's a UI issue then. So are you going to put it in Preferences or the View Menu? Those are your only two choices. Putting it in the QA menu is the equivalent of removing it from the UI. And don't tell me that the language selection in the profile manager is good enough because that doesn't let me change the language on an existing profile. Where does everyone get the opinion that noone needs this menu? Is it based on personal opinion? How many of you speak a language other than English? And why is everyone focusing on individual users here? Do you think that no big international company would want to roll out Mozilla? If we are going to start getting rid of unused menus, let's start with the "Use Stylesheet" Menu that defaults to none. or how about moving the Sidebar menu to show/hide where it belongs? Why do we have a translate menu that just opens up a web page? I think I know why. As I said in another bug, Mozilla is a developer release. We create the technology, then people modify that technology to suit there needs. We provide ABCD and they take ABD. We should be providing ALL the technology, and letting people take what they need and remove the things they don't want. If you don't like the menus within Mozilla, then by all means create ReallyGreatUIzilla and change it. Why do you have to impact all of Mozilla to do these things? And incidentally, the way most groups/companies decide these things is NOT with a UI person or expert or committee. It is with a usability team that takes real world people off the street, has them use stuff and see what they think of it. Maybe that's what we need here. We don't want to end up with a UI created by developers like Opera.
(ftang using jbetak's accout) not critical to moz0.9.2, move it to moz0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Saying that it is OK for Mozilla to have a cluttered UI because some distributor will clean it up is like saying that it is OK to ship a broken layout engine, because some distributor will fix it. Other examples of menu clutter don't make this case less worse. In an international company individual employees are very likely to have their own profiles. In a kiosk setting the UI will be minimized anyway and is likely to display only very basic navigation buttons with more or less universal symbols. (I can speak [and read] languages other than English.) I'm repeating myself but from a UI design point of view this is quite straight-forward: Oft-used items go in menus. Seldom altered settings of the more permanent nature belong is prefs. End users don't change the UI language often. They users either never touch the setting (and use the US Engish version) or then they change the language once and then let the setting be. Only localizers and localization testers need to switch the language often. Hence, the setting that end users see should be in prefs. If localizers and testers want to *also* have menu items, those menu items belong in the QA menu. Putting the language switcher in the View menu increases unnecessary clutter and thus lowers usability.
> OK, it's a UI issue then. So are you going to put it in Preferences or the > View Menu? Those are your only two choices. Based on the views of all 3 people concerned with designing the Mozilla UI, the View menu is not a choice. And I would reiterate, as this seems to be getting lost, that there are serious technical issues with the current implementation. Putting it in the Preferences panel is, as you know, bug 65251. Ben has said in that bug: "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" and also "I can see a potential use for UI language switching." He does not seem totally averse to UI Language switching in the Preferences panel if it's invisible in the standard case. Also, there are patches in that bug. I would suggest that the best way to get this UI in Mozilla is to take the patches in that bug and make those preferences panels visible only if there are multiple langpacks (and content packs, for the content stuff, I suppose) installed. > Putting it in the QA menu is the > equivalent of removing it from the UI. Yep. It was to be removed originally but mpt suggested to move it to QA to make the job of i18n QA (who will switch langpacks daily, no doubt) easier. > If we are going to start getting rid of unused menus, let's start with the > "Use Stylesheet" Menu that defaults to none. We want to encourage use of author stylesheets. Hiding the UI will defeat this objective. > or how about moving the Sidebar menu to show/hide where it belongs? There's a bug on that: bug 79639. > Why do we have a translate menu that just opens up > a web page? And that too. Bug 77207. Gerv
I have beeen reading this debate and there seems to be severel issues that need adressing: 1. This is Netscape only (Regional content) Wrong. Translation or localizing the regional content is being done actively by those people, who translatte the language "content". Those localizators are not netscape only they are Mozilla contributers Mozilla.org currently has 58 registered locales My site MozillaTRanslator.org has an equal amount. 2. Do we need a UI for language selection ? Yes we do, just as well as we need a themes selection. I normally only change the theme the first time the browser is run, and it got a UI. Basicly we need a UI because if people only use one profile, (as most end users will) they will never see that they can switch language.So they are missing out on a great feature, and somthing that has got a LOT of outside contributions. 3. Where shoud the UI be ? a: the QA or debug menu Absolutely not, since this is like removing it, and it will then disapper in the commercial distro, this is not a option. b: the view menu Possibly. I switch language as often as I switch Theme. Perhaps this not often enough to warrent a permanent stay in the view menu, but we should NOT move it to QA/Debug c: The preferences: Naturally. Ofcource the Language selection should be in the preferemces. My suggestion. 1. Make a preference Panel for language and regional switching 2. Leave the current UI in the view menu, and when "1" is completed, then it might be taken up to reconsideration. Perhaps the wording in the menu could be improved. I recommend this bug be resolved "WONTFIX" Further debate should be done in netscape.public.mozilla.l10n Henrik Lynggaard MozillaTRanslator.org
> 1. This is Netscape only (Regional content) > > Wrong. Translation or localizing the regional content is being done actively > by those people, who translatte the language "content". Those localizators > are not netscape only they are Mozilla contributers You are aware of the difference between "content packs" (which still seem to me to be Netscape-specific - special home pages, search links etc.) and "language packs" (which no-one disputes are a Mozilla thing), right? Or are the localisation teams localising the content packs as well? (Has anyone ever seen one of these Content Packs? Where can I download one? The only definition I've ever found of what they contain is 2 lines long.) > 2. Do we need a UI for language selection ? > > Yes we do, Is there anyone who disputes this? I don't think so. Some people think it should only be visible when you can make the switch, though. > a: the QA or debug menu > > Absolutely not, since this is like removing it, and it will then disapper in > the commercial distro, this is not a option. As I have explained several times, moving it to QA is equivalent to deleting it; it just makes it available to testers. No-one is suggesting moving it to QA and making it the _only_ UI. Gerv
> Or are the > localisation teams localising the content packs as well? Yes! > (Has anyone ever seen one of these Content Packs? Yes! I have even written one. > The > only definition I've ever found of what > they contain is 2 lines long.) Then please read the entire bug report before commenting. See my comment from 2001-05-19.
Karl Ove Hufthammer , Henrik Lynggaard Hansen , and Henri Sivonen Many thanks for jump in and contribute your opinion. >1. Make a preference Panel for language and regional switching >2. Leave the current UI in the view menu, and when "1" is completed, then it >might be taken up to reconsideration. Perhaps the wording in the menu could be >improved. This approach won't work if we still need to have a way to download more content / language pack. The preference dialog is model, there are no way wen can bring up a download page from preference window. We still need to keep this menu even 1 is finish so user can download more pack.
The View menu is a very strange place for a menu item that takes you to a Web site. Couldn't the default bookmarks and the Bookmarks menu be used?
Henri Sivonen, did you read mkaply's comments (2001-06-05 12:31)? he specifically mentioned the translate menu item which jumps to web content. 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).
Timeless: Yes, I read the comment about the "Translate" menu item and examples of suboptimal menu design. My comment on it became blurred because of an embarassing editing blunder. I'm aware of the "Translate" and "Get New Themes" menu items. In my opinion (based on the usual expectations about the function of the View menu), putting menu items that are actually hard-coded bookmarks in the View menu is strange. I don't think it is a good idea to introduce more such menu items.
adding dependency on bug 84232, we need to open a new browser window from the pref panel to allow download of additional language/content packs
Depends on: 84232
jbetak: Why can we not have a "Download Additional Language Packs" item in the default bookmarks, as someone else suggested? Opening new browser windows from modal windows can only be achieved in an ugly way. It would be good to avoid it. Gerv
gerv, on principle I'm not opposed to that idea. I'm merely attempting to follow German's UI design recommendation. Ultimately, I'd like to see an RDF-based pop-up list of available language/content packs in the pref window, although this might never happen. A problem I could see with the proposed new bookmark is, that users will potentially never discover it. Keeping related UI together might be in some ways preferable. Opening a full browser window from prefs is indeed ugly - see just how ugly in a precedence case I found in Prefs->Navigator->Smart Browsing->Internet Keywords->More Information And how about having both, the download button on the pref pane and the bookmark?
Juraj/Gerv - Pls see the last comments in Bug 65241. If either of you can help pull this off, I think Hangas (German's boss and ME), would agree with you on this one (i.e. We will ammend the spec).
jamiejr: I don't understand what's going on in bug 65241. Has it morphed into a request for a mechanism to open browser windows from prefs via a request to close the preferences dialog? If so, I need to point out that my cycles are currently extremely limited for various reasons, and I wouldn't be able to do that for you. I'm still of the view that the default bookmarks should have an "Extend Mozilla" folder which should have several items: Download Themes (themes.org or netscape.com), Download Language Packs and Download Content Packs (both netscape.com, with a page explaining what they are when you get there.) If anyone opens their default bookmarks, (and you'll agree that almost all users do) then they will see these. "Extend Mozilla" sounds exciting. I disagree that this is splitting UI concerns; after all, we don't have "download themes", "download plugins", "download helper apps" buttons in the prefs. Gerv
mark it as future.
Target Milestone: mozilla0.9.3 → Future
This bug seems cannot reach agreement with the UI discussion. I think we should mark this future for now since we cannot reach agreement about what the ui should be. We should leave this menu item in the view menu untill we have a way to solve the download issue. We cannot put the downlaod in the pref since pref dialogbox is modal. and we should not move it intl debug since changing language and region setting has nothing to deal with debug. People really need this feature, look at how google adopt language setting. Change your langauge setting in the pref and visit www.google.com, you can see they will switch the server ui on the fly UI. This is an very very useful feature. We simply need a client side switching here.
*** Bug 90046 has been marked as a duplicate of this bug. ***
Keywords: intl, nsBranch
Blocks: 99171
nsbranch- since Frank moved it to future
Keywords: nsbranch → nsbranch-
Blocks: 107067
Keywords: nsbranch-
jbetak's contract is up. Bulk move bugs to ftang
Assignee: jbetak → ftang
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
No longer blocks: 107067
This is fixed now. Someone please mark this bug to reflect that.
I think the current situation has definitely bypassed this bug. Punters still unhappy with it should file a new one. Gerv
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
> People really need this feature, look at how google adopt language setting. huh? Are you sure that "Languages and Web Content" really alters the pages Google gives you? As I understood it, that wording is a miswording, as it changes the UI langauge, the lang part in the UA string, and the builtin link crap only. Practically no website looks for at the lang part of the UA string, however, as we have a special HTTP header for that: X-Accept-Language. And that header is *not* influenced by that menu item, but the Navigator|Languages pref panel. Or am I wrong? Compare bug 114803 and bug 55366. For the record: I am for removing the menu item altogether (we have a pref panel now). (I am German, before anyone says I were English-biased.)
> huh? Are you sure that "Languages and Web Content" really alters the pages > Google gives you? As I understood it, that wording is a miswording, as it > changes the UI langauge, the lang part in the UA string, and the builtin link > crap only. Plus the default setting of the http header: accept-language. > Practically no website looks for at the lang part of the UA string, Just the opposite. Have you ever visit international webistes with a properly localized browser? Although, the purpose of the lang part of the UA string is not for server content negotiation, there are a few big websites sniff this info and redirect users to proper pages. > however, as we have a special HTTP header for that: X-Accept-Language. Are you referring to the "X-Accept-Language" in the mail header? If so, it *IS* influenced by the Accept-Language field of the HTTP header as described in RFC2068. > And that > header is *not* influenced by that menu item, but > the Navigator|Languages pref panel. This is exactly the Accept-Language field of the HTTP header. Its default setting comes from the UI language pack, en-US.jar in the US build. Messenger uses this value for its X-Accept-Language field. >For the record: I am for removing the menu item altogether (we have a pref panel >now). (I am German, before anyone says I were English-biased.) Discoverability is the issue here. Mozilla's download statistics does suggest that people use langpacks a lot even when there is a full-localized build offered.
> [UI language is] the default setting of the http header: accept-language. I didn't know that. This is a bug, see bug 55366. > Have you ever visit international webistes with a properly localized browser? Yes, I have, Google and www.debian.org for example. And they use Accept-Language, not the UA string, I think. > > however, as we have a special HTTP header for that: X-Accept-Language. > Are you referring to the "X-Accept-Language" in the mail header? No, I meant the HTTP header "Accept-Language", sorry. > Discoverability is the issue here. I argued about that in bug 114803.
> And they use Accept-Language, not the UA string, I think. Actually, I am *sure*, because I send "en" in the UA string, but "de" as first choice in Accept-Language, and I get German pages on both sites. UA string sniffing makes no sense to me, given that that we have a special HTTP header for that. Anyways, the lang in the UA string and the first lang in the Accept-Language header should be the same.
> UA string sniffing makes no sense to me, given that that we have a special HTTP > header for that. Agree. Accept-language is for such purpose. I was pointing out the fact in the real world. > Anyways, the lang in the UA string and the first lang in the > Accept-Language header should be the same. No, while accept-lang is for server content negotiation, the lang code in U-A is to identify the browser's localization characteristics. The former is customizable by end users; the latter is not.
> while accept-lang is for server content negotiation, the lang code in U-A is > to identify the browser's localization characteristics. The former is > customizable by end users; the latter is not. Again, please see bug 55366. Everything lang-related that we send to the server must be user-customizable (independant of the UI lang). I'd have more to say to that point, but it's offtopic here, so I won't.
mass-verifying WorksForMe bugs. reopen only if this bug is still a problem with a *recent trunk build*. mail search string for bugspam: AchilleaMillefolium
Status: RESOLVED → VERIFIED
Component: User Interface Design → Browser-General
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: