Multiple locales in manjaro-architect

Continuing from Architect: Locale settings - Swedish with American English language

I plan to work on this feature next, based on my experience on setting the correct settings on vanilla gnome installed with manjaro-architect. To get the correct settings, I had to

  1. generate an extra (finnish) locale
  2. choose english for language and finnish for units in gnome settings

So, ideally manjaro-architect should generate two locales when needed and set one for language and one for units and stuff. I think Calamares gets the other locale based on your time zone choice. That is challenging to implement, because it would require a static mapping of all time zones to certain locales. Possible still, because the output of timedatectl list-timezones is not that long. If someone can provide an list of correct locales for all time zones, I can try this approach.

The other option is to make the locale choice a multi selection operation. Then, at minimum add locale files to the file editing list. Or, if you chose more than one locale initially, set one for language and one for the other variables.

Any help and ideas is appreciated. @Beardedgeek72, you might be interested in this.


Thank you.

As a side note in the meantime for people installing with Architect, or pure Arch, or anything else that doesn't set it automatically: I have found, quite logically, that if you think backards it's much less work when manually assigning locales.

The natural way is to think "I want American text, so that's what I am going with". But then you have to edit much more lines than if you do it the opposite way: Pick the locale that fits most of the settings, and then you only have to edit the one for the display language afterwards.

1 Like

I mostly use bspwm, so the language is pretty much the only setting that affects anything. But on gnome the calendar week started on Sunday, and that is just not okay. So I finally got around to fixing this.

So, to get the correct measurements automagically like calamares does, I would need a correct locale for each of these cities:

awk '/\// {print $3}' /usr/share/zoneinfo/ | cut -d'/' -f2 | sort -ud

So, 404 cities to be paired with locales. Preferrably a list formatted something like this:

Helsinki fi_FI.UTF-8 UTF-8
Stockholm sv_SE.UTF-8 UTF-8
Moscow ru_RU.UTF-8 UTF-8
Kiev ru_UA.UTF-8 UTF-8

I tried to check how calamares does it, but they don't seem to be using a static list. So, probably not useful for bash based installer. A static list would be the easiest to use from coding perspective, it's not like this data changes very often.

1 Like

The cost is 2,85 MiB (tzdata).


  • A system locale and a new user default locale
  • System locale is usefull (advised) to be American-English as standard default messages are anyway on this. Then as the user may like otherwise (against my advice :stuck_out_tongue_closed_eyes:), can easily change it after 1st boot
  • Default user locale by XDG (I think) has local override files at

This can be set at /etc/skel/.config/locale.conf for all new users, including admin (sudo) user :man_shrugging: .

  • A user default locale is "fair" IMHO and sensible, as it conforms with most user cases (if not all), including the Linux way of configuration (multiuser).
  • The most important of all the above (IMHO) is the keyboard layout for non-English users, to be setup properly with TWO (or... more than one) keyboard layouts active as user default.
    This could be adjusted from the installation phase, also as a default user setup (user choice in M-A) and make it a treasure feature.
    It needs an Xorg conf file for the GUI, that is normally done by localectl. I don't remember exactly the (file) setting for console, it's also setup by localectl.
    I don't know if that's doable at the M-A installation sequence, but I am willing to help make it happen.

Mostly applies to non Latin keyboards like greek and cyrillic. Plenty of non-English keyboards like Finnish, German etc have no need for dual layout. But yeah, automatically setting that where appropriate would be sweet.

Probably doable by making the keyboard layout selection checkbox based instead of radiolist.

1 Like

I started a list, 28/404 done. Please contribute if you would like this feature.

1 Like

that's actually not really possible.. as example my country only have one timezone Europe/Zurich but the locale can be fr_CH, de_CH or it_CH :wink:

Can you please explain the scope of this project?
Isn't those data already in existing DBs on our systems?
I am sure wikipedia has relevant info. I may check, but what exactly do you want to match?
If I kind-of understand, what about people abroad (travelers - imigrants)?
This "match" should be an install time user choice, IIUC.

Question: I am not a programmer of note at all but this sounds like it could be scripted like I already have done it manually:

Two questions: Language and Locale (for units and timezone).
Even if you ask them in this order, which is more logical, just shuffle the Language choice into a variable. Then set the entire locale according to the second question. Then script a change in locale.conf(?) to alter display language according to the first question.

Again, I don't really know what I am talking about but it seems to me Architect is already doing more advanced things script wise?

The automatically selected locale would be be used only for measurements, dates and stuff like that. Language and keyboard layout would still be manually selected by the user. I assume that *_CH locales would have the desired features in common?

Yes, the technical part is not very difficult to do. The challenges arise from two things:

  1. which interface is the best for the user?
    A) have two consequtive radio menus like the one we have now: "select system language" and "select system locale (date, measurements etc)"
    B) have one tick box menu where the user can select as many locales as they want. If more than one is selected, have 2 radio menus to ask which one is for locale and which one is for language.
    C) choose the language like now, but set locale for measurements based on the selected time zone (this is what calamares seems to do)
    D) something else
  2. what data is needed for automating the process?

If that data is already somewhere, I very much appreciate if you can point me to it. I glanced through calamares source code and it seems to me that it uses some existing python (or c) library to pull that data. Replicating this in bash is beyond my current abilities.

Currently, I think that the best choice is

  1. move time zone before the locale choice
  2. detect locale based on chosen time zone, but do not set it yet
  3. have two consequtive radio menus like described in 1A, but for language preselect en_US and for locale preselect the auto-detected option.
  4. if no choice is made, generate these defaults when exiting installer.

This gives the user full control over the system, but also gives sane defaults by repeatedly pressing space.

1 Like

Besides dates I think yes.. to be honest I never tried other locales of my country than mines :grin: I'm more used to en_US than them. Days, month won't use the right language I don't know if we have difference in format but it would just be the string format.

Calamares seems to try to guess locales by using the languages and the country code taken from the time zone (I did not check exactly how he extract the country code) and it has speciality for some case and check if the guessed locale is valid and if not fall back to en_US. (Like as Spanish people who choose to install in Spanish in my country as es_CH is not a valid locale) I'm not really sure about the fall back I checked on my phone and it's not ideal to check code :sweat_smile:

And I can't say if he guess right in my case as I always install my system in English and change locales afterward only for my user

1 Like

There is several ways to achieve info on the current location.

Calamares uses a geoip service which returns the time zone.

Pacman-mirrors also uses a geoip service but also has database of timezones/countries.

To obtain the users current IP adddress can be done in any number of ways but is not valid if using a VPN service. can return a number of information depending on endpoint docs

The file /usr/share/zoneinfo/ also contains zone table.

That seems useful, thanks!

I don't think auto-detecting time zone is necessary, the current system based on works pretty well. The only difficulty is deriving the locale from the selected time zone.

I think I can start implementing the rest of the plan first and add the autosuggestion later when the data is available. @cscs made already a large contribution and with the database you provided it seems reasonably easy to compile.

IP geolocation is used initially to derive the default timezone I think.

Each Calamares install I do defaults timezone to the country of the VPN server I am connected to, then bases locale settings (ie language, date / time formats, etc) on that.

FWIW I think a single locale should be the default still, with an extra manual step required if a secondary locale is desired.

Neither is for locale to auto guess.
Thinking OOTB you may see it's an ad-like wow feature with no real sense. My daughter and friends being in Netherlands or Belgium will need the same setup as my cousins at Melbourn and Toronto.

Also I tried to explain, I don't know if I was understood or just disagreed.
System language and locale is not the same as default user language and locale. System setup is used by the admin, which should be English, except exceptions.
This is not how those are currently handled in Manjaro or Arch, but it's the sensible thing to do IMHO.
Thanks for listening :wink:

The current implementation on the local branch is following:

  • locale menu first asks for system language. En_US is preselected and message explains that English is recommended for easier troubleshooting
  • then, it asks for system locale, explaining that it is used for time format and do on. En_US is still preselected.

As a next step, the latter menu would have automatically detected locale preselected. User can still use any locale they want.

I thought I understood, I made it fully configurable because of your feedback. Nothing is set automatically.

1 Like

What kind of workflow would you suggest? Triggering the locale menu twice, and locale gets appended instead of overwritten?

  1. locale menu first asks for system language. En_US is preselected and message explains that English is recommended for easier troubleshooting
  2. If the user chooses a non-English language, remember this to add/set secondary keyboard layout(s) for system wide (xorg conf - localectl command)
  3. then, it asks for ~system~ locale, explaining that it is used for default time format and do on. En_US is still preselected.
  4. if the user selects a locale different than previously (1) selected language, present a selection menu with specific settings (names could be user friendly, instead of ENV VARS i.e. "Address" vs "LC_ADDRESS") :

Ideally, each of the setting should have a possibility to choose any available value, which would make this page/section a select menu, instead of check-boxes, having in mind (informing the user) that if not setting a different value than system locale, defaults to system locale.
For example, locale.conf could have only LANG and the different locale VARS set only.


About console font setting and more on configuration files in my tutorial. I still forget those and go and read what I wrote :laughing:.

I still discover more...
$LANGUAGE is an array. Don't ask how it is filled, I just discovered...

$ localectl status
   System Locale: LANG=el_GR.UTF-8
       VC Keymap: us
VC Toggle Keymap: grp:alt_shift_toggle
      X11 Layout: us,gr
       X11 Model: pc105
     X11 Variant: ,
     X11 Options: grp:alt_shift_toggle

$ echo $LANGUAGE

$ echo $LANG

$ cat /etc/locale.conf 

Not sure.

The manual workflow would be to uncomment multiple locale.gen lines, generate locales, then edit environment variables in locale.conf if LANG and other LC formats differ.

Then you've got various DE differences that may need to be manually handled post install (ie Gnome).

As for how this would work in M-A you could allow selection of multiple locales, then allow editing of locale.conf later if multiple locales selected. This way the LANG could say be en_US and other display formats could be more regional (ie numbers, timedate, money, etc).

I don't think DE specific overrides should be included in M-A, just locale.conf editing.

I see it as a simple file edit process, like editing journald.conf currently post install, just list the currently installed locales in the description text and let the user do the work. If the user doesn't know what locale.conf is they probably shouldn't be using M-A in the first place.

Is this kind of what you had in mind or am I missing the point?

1 Like