Closed Bug 181541 Opened 23 years ago Closed 21 years ago

Add UI to set default languages for web pages

Categories

(Firefox :: Settings UI, enhancement, P3)

Product:
Firefox
Component:
Settings UI
Type:
enhancement

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox0.9

People

(Reporter: tpowellmoz, Assigned: steffen.wilberg)

References

(
URL
)

Details

(5 keywords)

Attachments

(2 files, 10 obsolete files)

screenshot to patch v2.2
8.34 KB, image/png
Details
final tweaks
27.86 KB, patch
mconnor
: review+
Details | Diff | Splinter Review
Some sites are available in multiple languages and automatically switch to your preferred language. For example, try Google. It would be nice if Phoenix let you set the preferred language much like Mozilla's Edit-> Preferences-> Navigator-> Languages. As it is, you can change the character coding in Phoenix, but you cannot change the language (unless it got moved somewhere that I missed). This is an important setting to be able to change if you want to browse in a language other than English. It is also important for public use computers where you have a people that use various languages.
I guess I should mention that I saw this in Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021119 Phoenix/0.4.
This will be returned when the phoenix installer is implemented.
*** Bug 184386 has been marked as a duplicate of this bug. ***
> This will be returned when the phoenix installer is implemented. Asa, do you mean you will not be able to change this from the Options window? Sometimes, you need to switch language on a site, and only allowing the option to be set from the installer would be a mistake imo.
OS: Windows 2000 → All
*** Bug 203490 has been marked as a duplicate of this bug. ***
I've written an extension to implement this feature, but I agree that it should be listed in the Options panel. http://www.vaelen.org/cgi-bin/vaelen/vaelen.cgi?topic=languagemenu-info
Andrew, Your extension is a step to the right direction. However, it has absolutely no use for me, since it does not support my language of choice: Finnish.
I have added Finnish to the extension. However, what I really need to implement is an option to provide a custom language string like Mozilla does today if the language you want isn't listed.
Andrew, why don't you just use the ISO 2-letter language code list ? http://ftp.ics.uci.edu/pub/ietf/http/related/iso639.txt I have the list of native names also if you want (i.e. names as written in the specified language : "français", "English", "Deutsch"...)
I was able to change the language by using about:config URL It could be nice to have the same preferences for it as in mozilla... Indeed sometimes, our language (french for me) is not available for the site I'm visiting, so we need fallback... so I need more than one language available Moreover, fixing the language during installation isn't a so good idea for me...We really need a preferences for it.
This is a feature request, as the bug is about adding UI to allow changing this preference after installation. I feel this would be best as an optional extension (especially if the installer allows customizing the install with extensions) rather than an always-on UI feature. Europeans speaking multiple languages would use this, while unilingual Americans and Canadians would likely never need or want this feature in the UI. Andrew's extension looks great and I would vote for including it as an install-time option, or possibly an installed and disabled extension. --> enhancement
Severity: normal → enhancement
Summary: Can't set language preference → Add UI to set default language
taking QA contact, sorry about the bugspam
QA Contact: asa → mconnor
*** Bug 217934 has been marked as a duplicate of this bug. ***
Guys, I'd like to morph this bug to have the Language Menu extension as an optional extension available via the installer. Any thoughts on this?
That sounds like a good idea to me. For me personally it is important to be able to change the language. However, I'm sure there are lots of folks who don't have this need.
That sounds good to me. Version 0.7 of the extension supports 437 languages and has localization packs for about 250 locales with localized versions of the various language names.
morphing bug as mentioned
Blocks: 214269
URL: http://www.google.com → http://www.vaelen.org/cgi-bin/vaelen/...
Summary: Add UI to set default language → Include language switcher extension with installer
On windows, firebird and/or the installer could use the Windows regional settings and use the language the user choose. This should work for 99% of Windows users. The typical windows user knows that when he wants another language he just have to change the regional settings. An extension is not needed for home users (as opposed to web experts).
The MSWin regional settings only let the user choose a single language/locale. But most users are at least passably multilingual, a situation which isn't well treated in a single-choice locale setting. That's why the extension is appropriate for most users. On top of that, the MSWin installer should indeed default to using the default regional settings in determining the browser's initial Accept-Language setting. I suggest using at least the data table in my Perl module Win32::Locale that maps MSWin locale IDs to IETF language tags: http://search.cpan.org/src/SBURKE/Win32-Locale-0.03/Locale.pm However, it wouldn't be a bad idea to prompt the user for confirmation, during installation, that the Accept-Language settings inferred from his OS local setting is actually correct. This step could also be used to prompt the user to select other languages that would accept web content in.
I absolutely disagree with the premise that most users are passably multi-lingual, at least in North America, as earlier mentioned. But using the OS-level settings as the default is a very good idea.
Yes, the US ("North America") is a minor exception to the general multilingualism of literate humanity. Still, it's just one country, whose populace is quite outnumbered by populace of the rest of the online world.
in any case, it still belongs as an extension (whether bundled or not) as for a significant proportion of the installer userbase, it is not needed.
I'm testing Firebird (after trying Mozilla navigator), and I really like it a lot!!!! I just didn't find any possibility of setting the language for the pages into the options windows, so I searched on the website, and discovered it must me set by modifying config files, but other people asked for this possibility into the options panel. Well, I agree. That's the place where, like all the other web browser, that setting must be, with the possibility of choosing the priority of different languages. Thanx PS. Great work! :-) Go on this way!
You do not want to inherit the page language from the system default... Consider the following two situations: * I have a Dutch Windows version as is being sold and delivered with OEM systems commonly here. However, like most Dutch people, my English is fairly good and I would rather read the English version of a page (usually the original) instead of a Dutch and perhaps awkwardly translated or delayed translation. * I have an English Windows version because I do not live in the Netherlands or it is not my computer but my university's, however I'd still like to read pages in Dutch whenever possible because it's easier, and has a certain coolness factor to it aswell :). Both seem very reasonable reasons to me :). So, although the installer could default to it, it should be made possible to change, and not through the system's default settings, it is easier and more intuitive to find in the options dialog, and as said before the system settings don't offer fallback language settings. I do not think the installer would need to prompt for it though, as that adds additional installation questions (which is not desirable I think), while most users (both English and non-English speakers) will probably want the system default anyway. About 'not including it for English users', I don't see why it shouldn't be. I doubt the overhead of this feature will be something to be worried about, and there are lots of examples where this can be useful, also in English speaking countries. And not always can such a use be foreseen at install-time, and often enough the installer is not the user so he might not see the need for it. * Suppose I am a Dutch exchange student on a British university, and the admins, not being multilingual, didn't see the need to install this. Being a mere user, I do not have control over an install-time decision. * Suppose in a (hopefully :)) not-so-distant future OEM systems get delivered with Mozilla Firebird installed instead of Internet Explorer, but the installation was once again done without this. Being a 'n00b' user, I find installing things difficult. * Suppose I am English, but after having installed Mozilla I am getting interested in the Japanese language, and take lessons in it. As an aid for learning, I'd like to read Japanese as often as possible, especially on pages which also have English translations available. Or perhaps I have teaching material which uses multilingual HTML. However, I would ofcourse first want to see the English Second, installation should be as simple as possible, I think. Not installing this means one option less in the options dialog, but on the other hand it *will* make an additional installation option, and if you ask me that isn't really worth it (well, perhaps, if you'd make a general 'include multilingual support' option which has effect on more (future) features than this one alone). Mozilla Firebird is aimed at the general public and should be as easy to install as possible (also for non-English speakers), so ideally it should only be a matter of clicking Next/Next/.../Finish, so to speak, and the user shouldn't have to make too much decisions (with little time to think about). After all, making the wrong decision here would mean you'd have to reinstall the entire program. Which the user may not be able to do due to restrictions. ~Grauw
By now the installer is already implemented, but not the language switcher. I find this is a needed feature, people will just not understand why they can see some of their favorite sites such as yahoo or msn in English rather than in their local language, as they do in IE. That's a very useful feature aimed at improving internet experience, we need it! So anyway... the installer has arrived, now it would be nice to see this included. By the way, it should be installed in the default installation. It wouldnt be logical to expect people who speak other languages to actually click on "custom install..." to select the option of installing a language switcher. To make it simple, I'd include it in default installation, even if without being asked it is initially set to English.
I don't understand the folks here: The extension as it is in the moment is the worst solution... Why can't firebird get normal language preferences like mozilla (and btw. *every* other gui-browser I know) has??? This is s elementary feature for all users, which don't have english as their mother tongue, and the setting of priorities via setting the languages a level up or down is really (as experience shows) the best method. E.g. I'm german, and I my settings are: 1. de-de 2. de-at 3. de-ch 4. es 5. es-es 6. en-us 7. en-uk Im really against adding bloat to firebird, but I'm certainly not willing to switch the accepted language in the tools menu. Let this be set once in the prefs-menu, and the user can surf without further concerning about accepted languages... Why should it go to the tools menu??? In my eyes thsi is certainly not a tool.... I really can't understand the 'english-as-mother-tongue' point of view here... sorry for the spam.
Keywords: intl
I'm taking the liberty of restoring the previous summary. Morphing bugs is a bad idea in general -- and trying to force the choice of a specific solution by morphing the summary when you're not the person in charge of choosing the solution and there is not consensus for that choice is a particularly bad idea. Furthermore, many users won't use the installer, either because it comes with their OS (e.g., many Linux distros), computer (a corporation-wide or university-wide install, perhaps), or because they install using some other packaging system (e.g., RPMs). It's also worth noting that the language UI in Mozilla is also where the default encoding for unlabed pages is set -- and that's a preference that users in many other parts of the world may need to make the web pages they visit most "work right" (but only because the web is a mess and we don't have the market power to fix it).
Summary: Include language switcher extension with installer → Add UI to set default language
I agree that we should add the UI for setting intl.accept-languages and intl.charset.default. Being able to select them while installing Mozilla is not equivalent to being able to change/set them while running. Trying to simplify FB, FB developers went too far removing the UI for intl.accept-languages and intl.charset.default.
Any progress already? You should just implement the language selector from the Preferences/Navigator/Languages menu from Mozilla, it's perfecly ok. By the way, to be honest, I find Mozilla's menu structure a lot clearer than firebirds... Maybe it can use a restyle. Anyways, off-topic. What this message is really about, as I didn't see it mentioned yet... If you are prepared to dig through Firefox's configuration settings a little (browse to about:config), then you can locate the key 'intl.accept_languages'. The contents of this variable is a comma-seperated list of languages you are interested in, in order of preference. Double-click on it to modify. By default this is 'us-en, en', so even most Brits should be interested in changing this to 'en, us-en' :). I, as a Dutchman, now have 'nl, en, us-en' there. If you don't know the code for your language, take a peek at the ones listed in Internet Explorer's or Mozilla's languages menu. So this is a nice intermediate solution for people who are really waiting for this feature (such as I). It's a bit annoying that Hotmail appears in English by default in Firefox, while there is a perfectly good Dutch version of it. With this change, my Firefox will from now on also give precedence to Dutch versions of sites. ~Grauw
For me, this is an important missing bug. 1) Living Belgium, we have websites with multiple languages. I want to control the language(s) served to me. 2) For testing internationalised sites, I need a flexible way to switch languages. This works great in Mozilla 1.6 but is missing in firefox 0.8. 3) The humor factor when setting multiple languages is just to great. Several sites will serve 1 page with, e.g., 3 languages intermixed <g>. I tried the Andrew's Language Menu extension (comment 6), but it doesn't solve 1), only 2) but in a quite convoluted way (to me at least). It should NOT be included in the optional extension via the installer, as suggested in comment 15. The solution most people would want, seems to exist in the Things They Left Out extension (http://texturizer.net/firefox/extensions/#ttlo) which is already heavily suggested for inclusion in the default list of optional extensions (bug 214269). It fixed all my problems with an intuitive interface that doesn't clutter up the menus to much. BTW, isn't Spanish a major second language in the USA? I'm sure the Hispanics would be very interested in having this bug fixed.
since we have an option to change character encoding in firefox (and no less than in a main menu! not tucked-away in a "tools->advanced->settings->advanced settings dialog ;), i say that the UI for languages should be in a default installation. compare the number of people that need to change, or even know what are "character encodings", to the number of people that need/want languages other than english. so, either drop the encoding menu from the view menu (not recommended), or add the language to the options. developers that vote against this option are the same kind of developers responsible for every second (desktop) application that has problems with non-english characters. there _is_ a life _outside_ of the USA, and outside the english language, just so that you know..
irst of all, I am pleased to see that my bug report spurred such a discussion among developers. I would like to add another argument in favor of language UI. There is a very common case where average Joe from anywhere in the world would want to change the language option of the browser. The most visited site in the world uses language negotiation in order to determine which in which language to serve its pages, and this site is Google.
*** Bug 241395 has been marked as a duplicate of this bug. ***
(In reply to comment #33) > *** Bug 241395 has been marked as a duplicate of this bug. *** it wasn't....
*** Bug 229932 has been marked as a duplicate of this bug. ***
Everyone can't read english US, so I would like to have the ability for the common user to change the default language for 1.0 + the value defaulting to OS level settings (ie Windows regional settings) at setup time.
Flags: blocking1.0?
Getting close to shutdown for UI changes... looking for ideas for how to do this effectively in Firefox's UI .
Keywords: helpwanted
Add it to prefences-general: A dropdown-field with all interesting languages (eg "English (en-us)") and one entry for manual setting, giving oyu the abilty to enter a code in textbox next to the dropdown-field.
(In reply to comment #38) > Add it to prefences-general: > A dropdown-field with all interesting languages (eg "English (en-us)") and one > entry for manual setting, giving oyu the abilty to enter a code in textbox next > to the dropdown-field. A good solution needs to allow the user to do any of the following: 1) select multiple preferred languages 2) enter an arbitrary language code 3) indicate priority among multiple languages IE 6 and Opera 7 provide good examples of how a language configuration dialog might look.
Something not too far from chrome://communicator/content/pref/pref-languages.xul, reached by a button in the Options' General tab.
If someone wants to take a stab at this, please feel free. Otherwise, -.
Flags: blocking1.0? → blocking1.0-
May I? I consider it important, and you guys told me to flag bugs... so... :) (Though I don't see how it is different from voting. Past 50 now, btw!) ~Grauw
Flags: blocking0.9?
(In reply to comment #42) > May I? I consider it important, and you guys told me to flag bugs... so... :) > (Though I don't see how it is different from voting. Past 50 now, btw!) > > ~Grauw THIS IS IMPORTANT. but as long as Ben don't think so... start to try to forget it. :-\
Oh, wait... 'Otherwise, -.' was referring to the blocking flag. Sorry... (terminology, sigh...). Well. I guess I could at least try to fiddle around with it a little if no-one else does. Only XUL and Javascript, right? Ha-hum...
As indicated in comment 30, why not work together with the people of the Things They Left Out extension (http://texturizer.net/firefox/extensions/#ttlo)? Most of the functionality is already there. I have no clue how this plays regarding licences, ... though.
i see no point in developing a language pack for firefox as long as there is no official extention that can easily added to the pack, that will add language switching UI.
oops, wrong bug.
Well then Ben, ok, I am fiddling with it a little now, this seems do-able. If I consider it important, I guess I'll have to do it myself :). What I'm basically going to do is taking the languages settings UI from Mozilla-the-suite and putting it in Firefox, borrowing from pref-fonts.xul and pref-fonts.js. That ok? ~Grauw
Laurens, have you already started? Because I've almost finished it :-/
This is basically SeaMonkey's languages dialog (from today's trunk). Changes to the 5 files I forked include: - used stringbundles instead of the deprecated srGetStrBundle; - renamed global variables to start with "g" (Ben loves this); - made dialogs resizable and persist size and position; - removed loads of unused entities from pref-languages.dtd; - lots of whitespace cleanup; I didn't modify the core functions in pref-languages.js, nor did I go through every line, because it works just fine.
Assignee: firefox → steffen.wilberg
Status: NEW → ASSIGNED
Removing the dependency to bug 214269, since this has nothing to do with the installer. Targetting for 0.9 :-)
No longer blocks: 214269
Hardware: PC → All
Target Milestone: --- → Firefox0.9
Attached patch patch v1.1 (obsolete) — — Splinter Review
- fixed a js strict warning - stringbundle only in pref-languages.xul - more whitespace cleanup and minor changes
Attachment #147850 - Attachment is obsolete: true
Steffen, can you upload some screenshot?
Attached image screenshot (obsolete) —
Here you are. The "Languages..." button opens the window on the upper right. It displays your current languages in the order of preference. To add one or more languages, click "Add...". That opens the window on the lower right. You can select it from the list or just type it in below. Click OK (or doubleclick) and it appears in the main window above. Specify the order of preference by clicking "Move Up" or "Move Down". The Character Encoding is specified by a dropdown menu.
looks fine, IMHO
Looks good. BTW, what happend to the 'Default Browser' option?
"Default Browser" is only implemented on Windows. It appears between the "Languages" and the "Connection Settings" buttons there.
I don't know if the "Default Character Encoding" UI should be left in. If the code shows that there's no relation between the default encoding and the languages then it should probably be removed.
That's cool. Glad that this is getting some attention, and it's probably easier for the reviewer if someone more experienced does it :). It's been a good learning experience in any case. I was about halfway, I got the UI in (and removed the character enconding thing since in firefox it's somewhere else already - View/Character Enconding/Customize), but the JavaScript was still giving me some trouble so that still needed some work and research (the JS console doesn't seem to show UI errors - at least not by default). I made the width 33em btw, it still allows the widest string to fit in, but is small enough to make the window not look funny (wider than it's large) when the character encoding is taken out. I see you also put in the seperator between the buttons, though mine was full-height and not 'thin'... ~Grauw
isn't the character encoding under View->Character Encoding already?
(In reply to comment #60) > isn't the character encoding under View->Character Encoding already? To the best of my knowledge, the two are not identical. View->Character Encoding is an interface for switching encodings. Languages->Default Character Encoding is a fallback setting that the browser uses with sites that don't specify encoding - it doesn't require the user to manually switch encoding. Prog.
In View->Character Encoding, you can switch the current encoding to another, after your page has loaded and you notice that it's not displayed correctly. In the Customize dialog, you can specify the items which appear in the Character Encoding menu. The customize dialog sets the pref "intl.charsetmenu.browser.static". On the other hand the default encoding, which is included in my new languages dialog, controls the pref "intl.charset.default". This charset is being sent to servers in the Accept-Charset HTTP header. And it controls the charset of a new tab or window. By setting the right default encoding, you make sure that pages use your preferred encoding from the beginning, so you don't have to switch manually each time. Jshin, am I getting this right?
lholst, thanks for the compliments. :-) Try these prefs in about:config: javascript.options.showInConsole, and javascript.options.strict. But the latter may result in flooding! ;-) What separator do yo mean? The <spacer flex="1"/>? I didn't modify that.
Firefox is not the Mozilla suite. I think that the "Default Character Encoding" is too technical for the home user, it's just confusing for him/her. For instance, IE doesn't offer this in its "Internet options" panel, but leave this in the View | Encoding main browser menu.
Flags: blocking1.0- → blocking1.0?
the equivalent option in IE is at internet options>general tab>languages button.
Ah, steffen, thanks for the info. The <spacer flex="1"/> I changed into a <seperator> so that the bottons have some space between them which makes things look a little less 'packed' (without, they will collapse) (unless you set a height ofcourse, but I think using a seperator is a better solution then). "Firefox is not the Mozilla suite. I think that the "Default Character Encoding" is too technical for the home user, it's just confusing for him/her." I strongly disagree. Firefox is aimed at the home user, but that doesn't mean all slightly technical sounding options should be instantly removed. IE doesn't do that either (not that that would automatically make a good argument ofcourse). If you're going to argument like that, might aswell remove the proxy settings, because even I don't understand them :). In any case, if they are confused by it, they probably won't touch it and leave it at its default. For some languages/web pages however it is probably important (think Greek, etc), and I personally would very much like to set that thing to UTF-8 instead of the default latin. But ok, that's not a home user issue :). Still though... It won't hurt anyone just sitting there at the bottom of that dialog. ~Grauw
Ben Goodger set blocking1.0-, so this doesn't block 0.9 or 1.0.
Flags: blocking1.0?
Flags: blocking1.0-
Flags: blocking0.9?
Flags: blocking0.9-
It was renominated because it now has a patch, which is a reasonable thing to do.
Flags: blocking1.0?
Flags: blocking1.0-
Flags: blocking0.9?
Flags: blocking0.9-
Attached patch patch v1.2 (obsolete) — — Splinter Review
The previous patch didn't apply cleanly.
Attachment #147880 - Attachment is obsolete: true
Hi! I have a few suggestions for changes (and yes the patch doesn't apply well, I just noticed, you were 15 minutes late :)): pref-languages.xul (line 87): - <spacer flex="1"/> + <separator/> This looks better, if you ask me, especially when it is not resizeable (in which case they will collapse to no space at all between them unless you do this). pref-navigator.dtd (line 32): -<!ENTITY languagesInfo.label "Select Languages and Character Encoding used when displaying pages."> +<!ENTITY languagesInfo.label "Set preferred Languages and Character Encoding for web sites."> This fits on one line, and reads a little better (but that might just be me). Further notes: Your language window is resizeable. Other preference windows (such as fonts, connection settings, etc) aren't. I suggest to set a width of 34em or 36em or so... Dunno exactly how to do that so I'll leave it to you :). I don't think I have any further comments on it right now... Looks good, also when seeing it actually working :). ~Grauw
(In reply to comment #70) > pref-languages.xul (line 87): > - <spacer flex="1"/> > + <separator/> I don't like that, becuase if you increase the height of the dialog, the buttons stay somewhere in the middle, which looks a bit odd. But I'll add |style="width: 30em; height: 30em;"| so the dialog looks better (until the user resizes it). > pref-navigator.dtd (line 32): > -<!ENTITY languagesInfo.label "Select Languages and Character > Encoding used when displaying pages."> > +<!ENTITY languagesInfo.label "Set preferred Languages and > Character Encoding for web sites."> Ok, but I'll have to adapt the "Fonts & Colors" label to that: "Select default Fonts and Colors for web pages." and "Select default Languages and Character Encoding for web pages." In the Languages dialog, I changed "Languages for Web Pages" to "Languages" and "Choose languages for displaying web pages." to "Choose languages you prefer." > Your language window is resizeable. Other preference windows (such as fonts, > connection settings, etc) aren't. I suggest to set a width of 34em or 36em or > so... Dunno exactly how to do that so I'll leave it to you :). Of course it's resizable, like the Cookie Manager, Password Manager and Image Manager dialogs. But I just noticed that the "Add Languages" dialog isn't resizable yet. I'll change that. > I don't think I have any further comments on it right now... Looks good, also > when seeing it actually working :). Thanks!
Attached patch patch v1.3 (obsolete) — — Splinter Review
The changes mentioned above.
Attachment #148302 - Attachment is obsolete: true
Oh, I think it should be <seperator flex="1"/> then :). A seperator should be equal to a spacer but with a min-height style set. If you ask me it is a better solution than setting a total window height, but it doesn't matter too much in the end. About the resizable window... Hm, you're right about the cookie manager etc., they /are/ resizable! That's pretty inconsistent then, because as I said, Fonts & Colors and Connection Settings /are not/ resizable... Anyways, what you might want to do then is set a minimum height so that it can't be resized smaller than the window's content fit...? But hm, well, never mind that then. Anyways it's good that you set a specific height and width for defaults... First time I tried the dialog it was like, 600 pixels wide. And if you're about to make some changes in pref-navigator anyways... Maybe you could incorporate the patch in my bug 242952 there as well :). Because I don't get much response on that one. Anyways, it works for me and it works good. Now let's try to get this in for 0.9 :). If there are any more issues the reviewer or superreviewer will probably address them. ~Grauw
> Oh, I think it should be <seperator flex="1"/> then :). A seperator should be > equal to a spacer but with a min-height style set. It's separator, not seperator. But I can't see a difference, especially there's no min-height on both. > That's pretty inconsistent then, because as I said, Fonts & Colors > and Connection Settings /are not/ resizable... That's because these two dialog always need the same space. The other dialogs may contain a lot of data. Therefore it's convenient to make them larger. The Options dialog itself is resizable as well by the way. min-height doesn't seem to work. > And if you're about to make some changes in pref-navigator anyways... > Maybe you could incorporate the patch in my bug 242952 there as well :). Sorry, but that wouldn't make this patch more likely to be reviewed. > Because I don't get much response on that one. You'll have to be _much_ more patient :-)
Comment on attachment 148311 [details] [diff] [review] patch v1.3 I think this is ready for review. Ben, please have a look when you've got a minute.
Attachment #148311 - Flags: review?(bugs)
Marking this as blocking 1.0+... Steffen, I'm trying to minimize the use of modal dialogs 3-deep in options as this really creates a mess on Mac where we end up with a bouncing dialog problem. (Basically you can only have one sheet open at a time so when you open a modal dialog on top of another modal dialog you end up with the parent sliding up then the child sliding down. It's really weird looking. What would be better (since I marked this blocking1.0+ you have a little more time to do this in) is if you were to either add a menulist under the listbox that showed the content of the sub-dialog or add a listview side-by-side like seamonkey's sidebar customization dialog. This would prevent a third level of dialog nesting. the menulist approach keeps the dialog fairly simple, but doesn't allow you to add more than one language at a time. Maybe that isn't a problem.
Flags: blocking1.0? → blocking1.0+
OK, the "Add Languages" subdialog is gone, and so is the "Add..." button. Instead, I've added a menulist below the active languages listbox. That looks much nicer than a second listbox. I also ripped out the code to add user-defined languages. If any language is still missing in our list of 167 languages, it should be added to that list.
Attachment #147882 - Attachment is obsolete: true
Attachment #148311 - Attachment is obsolete: true
Attached image screenshot to patch v2.0 (obsolete) —
Attachment #148311 - Flags: review?(bugs)
Comment on attachment 148642 [details] [diff] [review] patch v2.0: menulist instead of subdialog Ben, how do you like this? I also attached a screenshot. I agree that a menulist looks nicer. The inability to add more than one language at a time doesn't justify an ugly dialog IMHO.
Attachment #148642 - Flags: review?(bugs)
I like the basic idea of this dialog box. However, IMHO, there is a small cosmetic improvements possible: put the 'Remove' button a little higher (right under the 'Move Down' button with maybe a little extra spacing). Now, it looks as if the remove button is linked with the menulist instead of with the listed languages.
Steffen, what steps you have to do to add a new language? I ask because I miss an "Add" button. You only have to select a list entry? IMHO we should support an additional add button. I also don't like the position for the "Remove" button.
I put the "remove" button next to the "Add a language..." menulist, because they belong together somehow. Add languages with the menulist on the left, remove them with the button to the right. But I can move it up of course. To add languages, click on the "Add a language..." menulist. A menupopup appears, just like the ones in Fonts&Colors. Then click on the language you want to add. The menupopup is closed and the language shows up above in the listbox, is selected and scrolled into view if necessary.
If you ask me, the list of languages should just be a list of languages with an 'add' button next to it, instead of the current click-in-menulist-adds-language way. The current method is at least not the way it usually works on Windows, and I don't really like it... If you click on the wrong spot, you have to select the item you just mistakingly added in the list above it and press remove and all... Nah. And the remove button should be next to the list of 'active' languages, preferrably at the bottom of it. Because it works on that list, not on the menulist with language choices. Er, what I mean is, add another hbox around the whole thing and pull the menulist out of its current hbox to the bottom of the new one. ~Grauw
Er, I meant vbox ofcourse. And the remove button should perhaps not be at the bottom of the active languages list anymore but just right below the move up and down buttons. It's cleaner that way, I think. ~Grauw
Steffen, the dialog for the fonts and colors hasn't the same behavior. There we only *select* an value out of an available list. Inside this dialog we are changing (adding an item to) the list of personally used languages which does more than only setting a new value.
(In reply to comment #77) >[...] I also ripped out the code to add user-defined languages. If any language is > still missing in our list of 167 languages, it should be added to that list. As the compiler of the language tags list ( http://search.cpan.org/~sburke/I18N-LangTags/lib/I18N/LangTags/List.pm ) I can assure you that there are more than 167 language tags. The LastTagsList has over 300, and that's even when it omits the redundant (but common) cases of country suffixes for languages spoken really in only one country (e.g., Danish). (But on principle, I'd also advise making there be a way for a user to specify a language tag.) But anyway, you're free to use the data in the LangTagsList (source at http://search.cpan.org/src/SBURKE/I18N-LangTags-0.30/lib/I18N/LangTags/List.pm ). Since new tags are still being by us in IANA, the list can't be called "complete" (like just recently we realized we were missing a tag for Haitian!); but it's pretty close, for most purposes. Incidentally, about a year ago, I was corresponding with the author of the Firebird plugin called Langlist about improving his classification and also adding the native names for languages (since lots of those billion-plus Chinese people don't know Roman script, so it would be really behoovey to have the Chinese glyphs for "Chinese" next to the English word "Chinese" in the options list. However, I got bogged down in the details and then me and my job got transferred to another town, and I basically forgot about the whole thing until now. Would the information I was trying to collect (namely, native name, and a what-continent-is-it-spoken-on token just to make multilevel list breakdown easier) be of use to anyone at this point?
(In reply to comment #86) > Incidentally, about a year ago, I was corresponding with the author of > the Firebird plugin called Langlist about improving his classification Oops, it was LanguageMenu. I am teh lame.
Thanks Sean, very interesting indeed. > I can assure you that there are more than 167 language tags. The > LastTagsList has over 300, and that's even when it omits the redundant > (but common) cases of country suffixes for languages spoken really > in only one country (e.g., Danish). Hmm, we've disabled another 90 languages: http://lxr.mozilla.org/mozilla/source/intl/locale/src/language.properties I don't know why. See bug 232487 for further reading. If anyone likes to add a language, please file a bug in Browser, Internationalization. > Incidentally, about a year ago, I was corresponding with the author of > the Firebird plugin called Langlist about improving his classification > and also adding the native names for languages Somebody who doesn't speak enough English will use a localized version of Mozilla or Firefox. The language names should be localized there, just like the rest of the UI.
(In reply to comment #88) > Hmm, we've disabled another 90 languages: > http://lxr.mozilla.org/mozilla/source/intl/locale/src/language.properties > I don't know why. See bug 232487 for further reading. I'm confused -- what does a "false" in that list mean? That it doesn't appear as an option in the menu for adding an Accept-Language? The saga at bug 232487 puzzles me. BTW, here, thru a bit of Perl ( use I18N::LangTags::List; local $/; $_ = <DATA>; use Text::Wrap; print wrap '', '', join ' ', map I18N::LangTags::List::name($_), m/(\w+ (?: -\w+ )? )\.accept \s+ = \s+ false/gx; ) is the list of all the languages at http://lxr.mozilla.org/mozilla/source/intl/locale/src/language.properties that have "false" : Afar Abkhazian Avestan Akan Assamese Avaric Bashkir Bihari Bislama Bambara Bengali Tibetan Breton Bengali Cree Church Slavic Divehi Dzongkha Ewe Fulah Guarani Gujarati Manx Hausa Hindi Hiri Motu Herero Igbo Sichuan Yi Inupiaq Ido Javanese Kongo Kikuyu Kalaallisut Khmer Kannada Konkani Kanuri Kashmiri Kurdish Komi Cornish Ganda Limburgish Lingala Lao Luba-Katanga Malagasy Marshall Macedonian Malayalam Mongolian Maltese Burmese Nauru North Ndebele South Ndebele Northern Sotho Chichewa Ojibwa Oriya Ossetian; Ossetic Panjabi Pali Pushto Rundi Romanian (Subform "mo") Russian (Subform "mo") Sinhalese Swati Southern Sotho Sundanese Telugu Tajik Tigrinya Tagalog Tswana Tonga (Tonga Islands) Tsonga Tatar Twi Tahitian Uighur Urdu Uzbek Wolof Yoruba Zhuang > Somebody who doesn't speak enough English will use a localized version of > Mozilla or Firefox. The language names should be localized there, just like the > rest of the UI. They /should/ use a localized version, if it's available. But I don't know if they actually do as often as they should. Hm. I'll ask around.
(In reply to comment #89) > > Somebody who doesn't speak enough English will use a localized version of > > Mozilla or Firefox. The language names should be localized there, just like the > > rest of the UI. > > They /should/ use a localized version, if it's available. But I don't know if > they actually do as often as they should. Hm. I'll ask around. If they don't they obviously speak enough English to use the software and can recognize the English name of their country without doubt... ~Grauw
I reworked the dialog to move the "remove" button up. I used a grid to make sure the "add..." menulist stays below the button even if the user resizes the dialog.
Attachment #148642 - Attachment is obsolete: true
Attachment #148643 - Attachment is obsolete: true
Attached image screenshot to patch v2.1 (obsolete) —
Btw, Ben removed the options panels of the old themes and extensions manager (i.e. I have nothing to do with it).
Attachment #148642 - Flags: review?(bugs)
Comment on attachment 149918 [details] [diff] [review] patch v2.1: move the "remove" button up Ben, I reworked the dialog according to comments in this bug. I also posted a new screenshot.
Attachment #149918 - Flags: review?(bugs)
Attachment #148643 - Attachment description: screenshot → screenshot to patch v2.0
I still think we should show localized names, but this can be a future adition.
"Choose languages you prefer" sounds a bit awkward, and "Languages in order of preference" below it makes it redundant.
Regarding comment 95: - IE6 has following wording: "Some web sites offer content in multiple languages. You can choose several languages below; they will be treated in order of priority." with the caption "Language:" for the listbox. - Moz 1.6 has following wording: "Web pages are sometimes available in more than one language. Choose languages for displaying web pages, in order of preference" with the caption "Languages in order of preference:" for the listbox. Maybe we should use Moz 1.6 wording (the best IMHO). There is repetition, yes, but it makes the meaning of the different controls clearer (again, IMHO). The "Remove" button is much better placed :-). Some vertical whitespace between the "Move Down" and the "Remove" button wouldn't be bad, but that's just me being a pain so feel free to ignore that comment ;-) However, I agree with Laurens (comment 83). The "Add ....." menulist should not both select and add the language. There should be an "Add" button next to the menulist so you can choose the language first with the menulist, and then add it with the button. Much cleaner according to our usability expert (and I agree). Oh yes, that usability expert would also like to drag & drop the languages around in the listbox. A shortcut for using the "Move Up" and "Move Down" buttons. IE6 and Moz1.6 don't do this, but it would make this dialog much superiour (read: intuitive) :-)
Wording: "Sometimes web pages can be displayed in more than one language. For these web pages, choose your preferred languages in order of preference." Listbox caption: "Preferred Languages:"
(In reply to comment #97) > Wording: "Sometimes web pages can be displayed in more than one language. I'd rather use 'are offered in' in place of 'can be displayed in'. Anyway, this is a very welcome edition to firefox.
I'll look at getting this in tomorrow.
Flags: blocking1.0+
Flags: blocking0.9?
Flags: blocking0.9+
Comment on attachment 149918 [details] [diff] [review] patch v2.1: move the "remove" button up I'm adding the much-requested "add button" right now. New patch upcoming rsn.
Attachment #149918 - Attachment is obsolete: true
Attachment #149918 - Flags: review?(bugs)
(In reply to comment #100) > (From update of attachment 149918 [details] [diff] [review]) > I'm adding the much-requested "add button" right now. New patch upcoming rsn. > Do it quickly please... Ben taought you finshed and he can land it in.
This includes the much-requested "add" button. I also changed the label to "Web pages are sometimes offered in more than one language. Choose languages for displaying these web pages, in order of preference."
Attachment #149919 - Attachment is obsolete: true
Comment on attachment 150164 [details] [diff] [review] patch v2.2: include an "add" button Ready for review (and checkin).
Attachment #150164 - Flags: review?(bugs)
Attached patch final tweaks — — Splinter Review
minor polish: disable the "add" button if the user selects a language which is not already active (button activated), doesn't click the button, then selects an active language. don't clear the selection after adding, the user might want to add another language/region nearby.
Attachment #150164 - Attachment is obsolete: true
Comment on attachment 150221 [details] [diff] [review] final tweaks minor changes only
Attachment #150221 - Flags: review?(bugs)
Attachment #150164 - Flags: review?(bugs)
Keywords: helpwanted
missing the boat, bigger bugs have just come up
Flags: blocking1.0+
Flags: blocking0.9-
Flags: blocking0.9+
Comment on attachment 150221 [details] [diff] [review] final tweaks I don't know if this is going to be the final UI, but r=me for the branch. Ben may tweak this somewhat, but this is something we should have for 0.9. Landed on branch to make the release.
Attachment #150221 - Flags: review?(bugs) → review+
Woaa, thanks Mike!!
Keywords: late-l10n
It works nicely, thanks ! Just a minor nit: I expect that new users want to "Add" a language because they want their favorite web site to show up in their language if it's available. So I would like that adding a language adds on top of the list, first position, instead of last position. The basic configuration steps would be to add my native language, then bump OK, that's all, don't need to "Move up".
Keywords: relnote
I agree with Bernard. I set this up on two computers and in both cases I had to move around... So it would save some effort when it'd insert at the top, I think. Another thing is that it of course does not initialize those values based on the language settings of the OS yet. Like, 'nl' only in the list on a Dutch system, and perhaps Belgian Dutch 'nl-be, nl' can also be easily detected. Similarly, 'en-gb, en' on a British machine instead of the current 'en-us, en'. This is something install-time, so it probably needs another bug created for it. But, very nice job Steffen. And I am glad to see this in 0.9.
If the correct locale can't (or won't) be detected, the default language should be just en; of course, it would be fr for French localisations, etc.
I guess I'll make that change to the "add" logic. But not for 0.9, there are still bigger issues to iron out. I don't think we have hooks to determine the OS language. These would've to be created for Windows, KDE, Gnome, Mac etc. separately. Pretty much effort for that little benefit. No no, I want users to gaze at my great dialog. ;-) Language packs provide different default settings anyway. Thanks for the compliments!
Priority: -- → P3
Target Milestone: Firefox0.9 → Firefox1.0beta
I'm marking this fixed since Firefox 0.9 shipped with this dialog. Please file new bugs for any problems and enhancement requests regarding this dialog in the Preferences component and assign them to me. I already filed bug 246827 "newly added languages should appear on top of the list". Adding "needed-trunk" keyword since this still needs trunk checkin.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Whiteboard: needed-trunk
Target Milestone: Firefox1.0beta → Firefox0.9
How these things work isn't formalised, but I think all/most of the other bugs that are fixed on the branch but not on the trunk are left open, but with "fixed-aviary1.0" in the status whiteboard. Bugs usually aren't resolved as fixed until they're fixed on the trunk.
Okay. Reopening for trunk checkin.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: needed-trunk → fixed-aviary1.0
Can we have a dialog to add custom languages? For example, Punjabi (pa) isn't listed in the default set.
I'd prefer to put the languages we need in the list of available languages. See bug 248690 for Punjabi.
Keywords: conversion
Flags: blocking-aviary1.0RC1+
Suggest clarifying summary of this bug to "Add UI to set default language FOR WEB PAGES". to better distinguish it from a bug to "Add UI for setting the language of the browser UI" (the latter is done in the Mozilla Suite by selecting a language pack in preferences | appearance | languages/content, and appears to be missing in FF0.9.1). Discussion on this was at bug 224194, transferred to bug 243113.
Summary: Add UI to set default language → Add UI to set default languages for web pages
Trunk checkin: 2004-07-19 15:38. I had to adjust to the locale change, and to bug 244624, which made the label property of menulists readonly. I had to use setAttribute() instead. For those interested, I just filed bug 252194 (newly added languages should appear on top of the list). Marking fixed!
Status: REOPENED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → FIXED
fixed-aviary1.0 is a keyword, switching to facilitate bug searches.
Keywords: fixed-aviary1.0
Whiteboard: fixed-aviary1.0
*** Bug 241653 has been marked as a duplicate of this bug. ***
Another case in point is MacOS X. This system allows different users to log in with their own language. On the same computer I could be using English, while my girlfriend is using Japanese. Since MacOS X involves a drag and drop install, from the disc image (dmg), this becomes a special situation, so the language support should be there by default. In fact, it should even detect the user's login language when the browser launches for the first time.
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change
QA Contact: mconnor → preferences
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: