310025 - Advanced/General/Languages must list ALL languages

Status: RESOLVED DUPLICATE of bug 356038

(Core :: Internationalization, defect)

Description

[Ramon Casha]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

The Advanced/General/Languages dialog in preferences ("choose languages web
pages are displayed in") currently only displays a subset of available
languages, and provides no way for users to specify a different language other
than the ones listed. This prevents Firefox from displaying websites in the
correct language for many users. This limitation is totally unnecessary, since
Firefox does not need to know anything about how that language works in order to
send the language code in the http headers. In fact, all I needed to do to get
the Maltese language in the list was to edit the res/languages.properties file
and set mt.accept=true, but users shouldn't need to do that and anyway I don't
know if that will affect other parts of Firefox.

I think we should either make the Languages list display all languages, or else
allow the user to enter the language or language-region code themselves.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Phil Ringnalda (:philor)]

*** This bug has been marked as a duplicate of 269437 ***

Comment 2

[Simon Montagu :smontagu]

From bug 62578:

------ Additional Comment #8 From Henri Sivonen  2000-12-12 14:06 PDT  [reply]
-------

The list of language code is here:
http://lcweb.loc.gov/standards/iso639-2/englangn.html

Wouldn't it make sense to add all the two-letter codes that aren't there already?


------- Additional Comment #9 From Katsuhiko Momoi 2000-12-12 14:23 PDT [reply]
-------

Henri > Wouldn't it make sense to add all the two-letter
      > codes that aren't there already?

Not really. Sending Accept-Language info to a server
should be backed up by the support for that language
in the client. We should not be including those that are
not supported in Mozilla.

From bug 310028:

 ------- Additional Comment #4 From Ramon Casha  2005-09-26 23:49 PDT  [reply]
-------

<snip>

I wonder whether bug 62579 comment 9 makes sense any more though. More and more
websites use utf-8 and the browser does not need to know anything at all about
the language being used.

Comment 3

[Simon Montagu :smontagu]

Bug 310028 comment 4 is an over-simplification: support for languages with
various kinds of complex text layout requires more than just decoding the
characters, and there are still some languages than can't be encoded even in
utf-8, (ae (Avestan) is the first example in language.properties).

Having said that, I think we might consider doing away with the accept=false
property altogether. We already have accept=true for a number of the Indic
languages where our support is rather spotty and platform dependent and I'm sure
one could easily find lots of inconsistencies in the list.

Comment 4

[Axel Hecht [:Pike]]

Let's ask the UI folks for some input on this, there are currently 80 languages
disabled. We accept some 180 ones. Do we want to make a cut, where, why?
And if we do, is editing about:config really the only way to get around it?

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

From reading bug 310028, I take it that the reasons some languages are disabled is that there may not actually be web servers that respond to the code, and our support for that language might not actually be there?

"Do we want to make a cut? If so, why?": It makes sense to me to only list the languages that we know we can render properly, and that we know will actually work with websites; otherwise we're basically surfacing useless UI and misleading users.

Comment 6

[Nicolas Barbulesco]

(In reply to Mike Beltzner [:beltzner] from comment #5)

> there may not actually be web servers that respond to the
> code

That may be true for Manx. But, in such case, let's do the first step. If Web browsers wait until Web servers respond to the code, and Web servers wait until Web browsers send the code, then nobody will advance in eternity.

Comment 7

[Gordon P. Hemsley [:GPHemsley]]

Wow, this bug is super old.

We're working on implementing BCP 47 in bug bcp47, including improving the Language selection UI. I encourage you to take a look at that bug and its dependencies, as well as the wiki article we've set up, which goes into more detail about a lot of things. Our work has largely superseded the discussions that went on here.

Our plans for implementing BCP 47 are somewhat long-term (because of the amount of work that it entails), but we're making an effort in bug 716321 to update the existing list of languages to take into account those which are already in common use around the Web.

It is my hope that we can somehow come up with a way to incorporate all languages tags at some point, including all their BCP 47 goodness, but the current UI is simply not set up to handle that. Also, it would be unreasonable to expect the localizers to localize the names of all those thousands of languages; our work on setting up an unlocalized master list is going on in bug 666662.

Since the work is going on elsewhere, in multiple parts, to make this happen, I think I'm going mark this as a dupe against the main bcp47 bug.