Closed Bug 181541 Opened 22 years ago Closed 20 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: 20 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: 20 years ago → 20 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: