Good question ;-)
I suppose you don't mean the browser menu language, but that of the displayed pages? Am not sure how many webmasters offer different versions for En-US and En-GB, but guess there exist mainly 4 prefs that deal with language settings:

Not quite sure what exactly each one does, except the first:
intl.accept_languages
It's written somewhere in the wiki, that this is the setting that tells a site which languages you understand, and e.g. it makes that you can see different language flags on that green navigation bar here in the forum. I've set it to "en-us, en, de, fr" and see now flags for german and french, and if I click e.g. german, the website appears in that language and the two flags switch to english and french.

Go to Edit > Configuration > Browser configuration
Accept the warning.
Type "lang" into the filter line, and change the two prefs as you wish.
Type "locale" into the filter line, and find the other two prefs.

I think there's not much of a risk as long as you only enter languages that you understand Just not sure if they all accept multi-languages?

Oh that actually exists? Very cool, I just recently thought that this would direly be needed! For example it always was a real problem to switch the wiki language back to the own language, once one had clicked the english flag. After much searching, I found one day the "Translation" page, with the embedded flags to click, and then had to hunt that down again for every switch. Not something I'd expect a casual user would bother to do. Until just some days ago Soeren posted that most helpful pref setting, that he had found buried somewhere deep down in the wiki. Shortly after, I wanted to compare something in Firefox, and was digging through the options there and there was this dialog, quite openly and easy for everyone to stumble over! I did think we'd really need that too

I guess this is a lost panel option when we migrated from old "Preferences" (C++ in K-Meleon code) to current "Advanced Preferences" (XUL in chrome).
I think this are complicated options to implement in XUL and with little use.
It's more easy change it from Edit -> Configuration -> Browser Configuration (about:config)

About this:

Quotesiria
For example it always was a real problem to switch the wiki language back to the own language, once one had clicked the english flag. After much searching, I found one day the "Translation" page, with the embedded flags to click, and then had to hunt that down again for every switch. Not something I'd expect a casual user would bother to do. Until just some days ago Soeren posted that most helpful pref setting, that he had found buried somewhere deep down in the wiki.

This web site preference is saved in a cookie, you can delete the K-Meleon cookie to return to english default language for K-Meleon web site.

Quotedesga2
I guess this is a lost panel option when we migrated from old "Preferences" (C++ in K-Meleon code) to current "Advanced Preferences" (XUL in chrome).
I think this are complicated options to implement in XUL and with little use.
It's more easy change it from Edit -> Configuration -> Browser Configuration (about:config)

IMO this language setting is of very important use!
Please, try to see things also from a "normal user" viewpoint, not only experts view. New users and the huge majority of casual users know nothing about "about: config", and either never realize such a setting exists, or if they know it from other browsers, they will start searching like crazy to find that global setting in KM-preferences too and give up frustrated, even give up the browser if they do need that feature. Even people who've used KM for years and work a lot with about: config may not have realized yet it does have such a feature (like myself)! There are hundreds of hidden settings in about:config, but who knows of them all, and additionally what each of them does exactly??

If you say it's easy to change it from about: config, why should the very same function suddenly become too complicated to change it from a prefs tab? Just a little input field with 1-2 lines of explanation and an example beside it. Even I could write a tiny little macro that pops up a prompt-input-field for that line, but this macro-created menu entry would just be in Edit>Configuration>Languages, rather prone to be overlooked there, while everyone would expect it on the prefs tab for "Page Display". Lots of space left there too...
I understand that to create the additional "drop-down-choice-list" would be complicated, but why not offer at least a little manual input field? That would be very much the goold old basic K-Meleon style too And certainly a snap for a developer, just a little input field for an already existing pref...

Quotesiria
IMO this language setting is of very important use!
Please, try to see things also from a "normal user" viewpoint, not only experts view. New users and the huge majority of casual users know nothing about "about: config", and either never realize such a setting exists, or if they know it from other browsers, they will start searching like crazy to find that global setting in KM-preferences too and give up frustrated, even give up the browser if they do need that feature. Even people who've used KM for years and work a lot with about: config may not have realized yet it does have such a feature (like myself)! There are hundreds of hidden settings in about:config, but who knows of them all, and additionally what each of them does exactly??

I'm sure that you are listen this before; "Search in Google, ask in Forum, in this order please."

Quotesiria
If you say it's easy to change it from about: config, why should the very same function suddenly become too complicated to change it from a prefs tab? Just a little input field with 1-2 lines of explanation and an example beside it. Even I could write a tiny little macro that pops up a prompt-input-field for that line, but this macro-created menu entry would just be in Edit>Configuration>Languages, rather prone to be overlooked there, while everyone would expect it on the prefs tab for "Page Display". Lots of space left there too...
I understand that to create the additional "drop-down-choice-list" would be complicated, but why not offer at least a little manual input field? That would be very much the goold old basic K-Meleon style too And certainly a snap for a developer, just a little input field for an already existing pref...

The problem isn't create the XUL GUI controls to do it or change the pref, the real problem is check that the imput value is an imput valid value.
I can't (I don't want) create a long list with all world languages. (Do you know all world languages string? I don't know it)
(Note that this list almost must be translated to all localizations)
If I created a single input box, how to check that string introduced is a correct language string?
If the 80% of the Internet users don't know difference between a browser and a search engine, how I can suppose that they known what is or what is his language string?
If we facilitate a pref modification we have to check that the value in pref is corrected/valid. Preferences with wrong values can produce unexpected and unwanted results. This can cause annoyance to users and they open bugs about it.

Anyway, I'll studied if it's possible the improvement of this option in Preference XUL panels. But not because this existed in old versions (I'm wrong in above post, this option never was included in old Preferences) else because this is available in Firefox 3.5.x and Seamonkey 2.0.x.

Quotedesga2If we facilitate a pref modification we have to check that the value in pref is corrected/valid.

I understand that as long as the internal function of the browser is concerned, but is it in this case really too?? Isn't this just a simple text string that is delivered to the website, but has no influence on the browser function itself...? Example: What happens if a user has an exotic but VALID language setting, and comes to a website like this here, which doesn't offer all 100+ world-language variations? What happens if a browser arrives here with a cherokee language setting? Would the websites reaction be any different than getting a non-existing language code?

I was just playing with this for testing. I am not proposing that I do anything with it yet. But the first thing is a big question. Why do I get a wrong answer with this code? I get a result of "chrome://nagivator//locale/nagivator.properties" when I expected to receive "en-us, en".

I tested and it works fine for me, James! (KM1.5.4)
Actually I'm surprised it works without putting quotes around the variable text - something I'm learning today? Quotes only needed if blanks or special characters in a string??
Am not sure what for introducing another variable, works just as well directly:
setmenu("_Config_General",macro,"Language Pref Choice",_LangPref_Run);

Anyway, why does it not work for you...? KM1.6?? What do you see in about: config when checking that pref?? Does it perhaps need custom settings, and that region stuff shows up if there are only the default settings, nothing in prefs.js??
Something dawning on me.... Isn't the local language chosen automatically at setup or some such...?? Meaning, probably defined in an unusual way, not via defaults/prefs...?

Just a quick guess:
Maybe it works with LANGUAGES ONLY? Without the region *extension*? Mine is just: de,en - not: de-de,en-gb (which I would choose had I the impression it would change anything ... No offence meant ...).

edit: PS: that guess was wrong - see desga2's posting, down 3 from this one.

Cheers
SoerenB

KM 1.74b4u1 in Wine 1.6 on Linux Mint 17 (XFCE)
- and still being surprised every day
how easily all of this works ...

This happend because the pref not exist really.
You can see in about:config, but only the browser show what is the default value for this pref, but this not exist in any preference *.js file.
If you go about:config and change it, really not need chage it, only do double click over the pref "intl.accept_languages" and click OK.
Now the pref changed to bold and the pref really exist in your prefs.js file of your profile folder. Then your macro work fine because can read the pref.

If you reset the pref, then path to chrome file is showed again in your macro.

The reason to show this string:
"chrome://nagivator/locale/nagivator.properties"
Or in my 1.6preBeta show:
"chrome://global/locale/intl.properties"
Is because this chrome files have the default pref values.
Indicating that you haven't setting this pref and the default value in this chrome file is using.

You can add this line to your \K-Meleon\defaults\pref\I10n.js file:
pref("intl.accept_languages", "en-us, en");

Or the macro can check if there's the properties-word in the result ;-)

Thanks for the explanations, desga!

Soeren, you shock me, how does that harmless menuline mess your menus?? Does it work better with the other version, the menu-name included directly, without variable?? Or do you just mean the sort order is different, since the menu-macros are executed alphabetically...?

desga2, I understand now. Don't think there is an easy way to tell a novice user how to make the pref available. I will likely look for the word "chrome" and report "Installed default" or something like that.

desga, i agree that this pref is of little use and becoming more useless because most websites nowadays rely on different methods for selecting language content.. the locale specified in the useragent string takes precedence over anything else and even when another language is selected, websites read that locale first.. another reason is the geolocation/ip discovery which is implemented in almost all modern websites..so they don't care about language preferences and display the language according to country of origin.. others that support several language content, neither care about browser specified language preferences nor ip discovery and just use english for the landing page with a language switcher available to the visitor.

implementing language preferences is by no means an easy task, it's very complicated in kmeleon and not sure if it's even possible whether in hard c++(original dialogue) or easier xul.. the languages dialog was always a stub in resources and was never used in any km version..probably due to the complications of such an implementation.. it's very easy to create a non-functioning dialogue and find out later that you simply can't use it. it isn't complicated because of the number of languages or validity check on add ..those are all built into gecko and can be easily checked, adding to prefs is no-brainer but the problem lies in populating:
1-the list according to user's previous selections(eliminating already selected languages/default locale-foolproof
2-displaying selected languages in a form so the user would knowwhich are the preferred languages
3-to a lesser extent, populate refresh on moving a selected language up and down the list

the reason for the population complication is because kmeleon being based on seamonkey misses a crucial comp service in populating those lists..the service relies on the seamonkey's built-in spellchecker which is not available for kmeleon..it might be possible to add an additional pref panel for languages content but it certainly won't be a "snap"

the easiest, least time-consuming for a feature that will eventually become obsolete and perhaps the only possible way.. is through macros like james did
..maybe make the macro a bit more complex at checking the user's input if it's a valid language code, using ini read perhaps?

the language codes supported by gecko are available inside km's root
resource://gre/res/language.properties

Now I see this other list inside KM. I had planned to write some program to redo the list I found down to just code space name and to provide that as a help file/validation file.

If this code is used by the website to decide which page to show, why do Gecko have false for some? I am late to the language game, having only English myself. So if my question sound dumb, it is because I am.

My plan was to create a pseudo indexed sequential file of the codes and do a binary search so not as many records would have to be checked. I won't get to work on this until next week. My wife and I are on trip to mountains and my laptop does not have all the tools that I need.

The question is do I continue to work on this or is it better in the prefs panel? Do I have to use the KM list to remove all the false entries? If I need to present the list as a help screen, what are the codes for Notepad to remove the menu so the user cannot change the file?

QuoteSoerenB
- Well, MHO concerning that, as you cared to ask: I'd rather have that in Tools/Settings, or /Misc, but that is not really a problem.

I think this sounds more like a config than a tool. We will see if others have comments on where to put it.