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:

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

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.

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.

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?

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.

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

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.