How do I change the default language from En-US to EN-GB, please?

Regards,

Bob Henson

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:

intl.accept_languages
intl.content.langcode
general.useragent.contentlocale
general.useragent.locale

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?

@siria
Funny, I understood his question differently (zumindest auf den ersten Blick).

@Galen
No en-GB language pack available for K-Meleon menu, only en-US, but you probably meant site default language, yes?

I've been reviewing my K-M 1.6 translation for couple days and now when siria mentioned website language, it came back to me :-).





It is one of dialogs in kmeleon.dll. So I wonder, why there is no such IMHO useful option in preferences panel?

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 :cool:



Edited 1 time(s). Last edit at 09/04/2010 06:15PM by siria.

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:

Quote
siria
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.

K-Meleon in Spanish

Quote
desga2
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 :cool: And certainly a snap for a developer, just a little input field for an already existing pref...



Edited 2 time(s). Last edit at 09/05/2010 07:57AM by siria.

Quote
siria
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."

Quote
siria
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 :cool: 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.

K-Meleon in Spanish



Edited 2 time(s). Last edit at 09/05/2010 11:14PM by desga2.

Quote
desga2
If 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?



Edited 1 time(s). Last edit at 09/05/2010 11:20PM by siria.

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

LangPref.kmm

#  K-Meleon Macros (http://kmeleon.sourceforge.net/wiki/index.php?id=MacroLanguage)
#
# ---------- LangPref.kmm
# ---------- View/Change language pref for viewing web pages
#
# Dependencies        : main.kmm, cfg.kmm
# Resources           : -  
# Preferences         : -
# Version             : - 0.1   2010-09-06 
# --------------------------------------------------------------------------------

_LangPref_Run {
macroinfo = _("View/Change current language pref");
$_LangPrefCurrent = getpref(STRING,"intl.accept_languages");
alert( $_LangPrefCurrent, _("Your current language pref is"), INFO );

}

_LangPref_BuildMenu {
$__l=_Config_General;
setmenu($__l,macro,"Language Pref Choice",_LangPref_Run);

}

## - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
$OnInit=$OnInit."_LangPref_BuildMenu;";
$macroModules=$macroModules."LangPref;";

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



Edited 1 time(s). Last edit at 09/06/2010 05:10PM by siria.

Hi, JamesD,

your code works correctly here!

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


Back again ...



Edited 1 time(s). Last edit at 09/06/2010 07:50PM by SoerenB.

Mine is "en-us, en, de, fr"
It's really just a simple text string, nothing 'computed' with it yet, just read like a phrase and displayed...



Edited 1 time(s). Last edit at 09/06/2010 05:15PM by siria.

Quote
myself
your code works correctly here!

... well, it wreaks havoc on my menus, which are widely customized, widely but not very carefully & not according to the rules.

PS: I tried again, moving it from the "Config" to my own "MyMisc" menu - now it's perfect.

Cheers
SoerenB


Back again ...



Edited 3 time(s). Last edit at 09/06/2010 05:39PM by SoerenB.

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");

K-Meleon in Spanish



Edited 3 time(s). Last edit at 09/06/2010 06:54PM by desga2.

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

Thanks everyone for your quick response.

Sira, I should have the quotes.

SoerenB, Sorry about your menu. Should I place this elsewhere?

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.

The list of codes is quite large. See this: http://www.loc.gov/standards/iso639-2/php/code_list.php

I am not even sure if this is the correct list. I don't see "en-us". I do see "en".

Found another list: http://msdn.microsoft.com/en-us/library/ms533052(VS.85).aspx



Edited 1 time(s). Last edit at 09/06/2010 10:03PM by JamesD.

This version has no validation or help. It does work, but the user has to know about the codes.

LangPref.kmm

#  K-Meleon Macros (http://kmeleon.sourceforge.net/wiki/index.php?id=MacroLanguage)
#
# ---------- LangPref.kmm
# ---------- View/Change language pref for viewing web pages
#
# Dependencies        : main.kmm, cfg.kmm
# Resources           : -  
# Preferences         : -
# Version             : - 0.3   2010-09-06 
# --------------------------------------------------------------------------------

_LangPref_Run {
macroinfo = _("View/Change current language pref");
$_LangPrefCurrent = getpref(STRING,"intl.accept_languages");
# check for default
if ( substr($_LangPrefCurrent, 0, 6) == "chrome" ) $_LangPrefCurrent = "Installed default";
#alert( $_LangPrefCurrent, _("Your current language pref is"), INFO );
$_LangPrefNew = prompt(_("Enter language codes to replace"), _("Current codes")."  ".$_LangPrefCurrent);
$_LangPrefNew == "" ? macros("_LangPrefCancel") : macros("_LangPrefChange");
}

_LangPrefCancel {
$_LangPrefCancel = confirm(_("Did you mean to cancel?"),_("Choice was cancelled"),YESNO,QUESTION);
$_LangPrefCancel == "YES" ? 0 : macros("_LangPref_Run");
}

_LangPrefChange {
setpref(STRING,"intl.accept_languages",$_LangPrefNew);
}

_LangPref_Def {
macroinfo = _("Reset language pref to default");
delpref("intl.accept_languages");
}

_LangPref_BuildMenu {
$__l="_Config_General";
$__lc=_("Language Pref Choice");
setmenu($__l,popup,$__lc);
setmenu($__lc,macro,_("Enter Language Codes"),_LangPref_Run);
setmenu($__lc,macro,_("Reset to default"),_LangPref_Def);
}

## - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
$OnInit=$OnInit."_LangPref_BuildMenu;";
$macroModules=$macroModules."LangPref;";

Hi, JamesD,

Quote

SoerenB, Sorry about your menu.

- No need to be sorry. Nothing I couldn't handle, and probably caused by my sloppy copying & some misconfiguration. All is OK, now.

Quote

Should I place this elsewhere?

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

Cheers
SoerenB


Back again ...

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

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

I thought I had a plan, but now I am not sure again. I had found what I think is an up-to-date language code list here. http://www.iana.org/assignments/language-subtag-registry I found that from this page. http://www.w3.org/International/questions/qa-lang-2or3.en.php

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?

Quote
SoerenB
- 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.

@ disrupted:

Yes it's, I known it. I'm working to adapt the Seamonkey 2.0.x XUL preference option for website Languages to K-Meleon preferences.
If this work fine I'll added it to preferences.

K-Meleon in Spanish

@ desga2

Since you are working on feature, I will no nothing more.