Furthermore I don't see the /etc/locales.txt in images I have now, so that could be a potential bug!

 issue 857024  is somewhat related, although that also involved looking at the locale registered by Chrome which wouldn't help in recovery

we prob should document language/locale selection in the new docs/os_config.md so we have an agreed upon method

I wouldn't really call it a "bug", just that we've always done it that way and nobody really complained enough to change it in 8 years. The firmware has its own locale setting in NVRAM, which is completely independent from both the default locale in VPD and Chrome's system locale stored on the stateful partition. As far as I know, we never initialize the NVRAM locale to anything, so it is always English out of the factory. It can be changed (and is sticky) by pressing the arrow keys on the firmware screens, but I bet almost nobody ever does that.

We could initialize the NVRAM locale to the same default that we store in RO_VPD in the factory if we wanted to, and we could also update the NVRAM locale every time the user changes the locale in Chrome. There is some trickiness involved to match the two up -- the locale in NVRAM is stored as a numerical index, and the index->language mapping may be different for every board. For newer (post 2015) boards it would be reasonably easy to load the 'locales' file from CBFS (on the firmware flash) which maps the indexes to simple locale strings (e.g. 'en', 'he', 'pt-BR' or 'es-419'). For the older bmpblk boards I think the same information is stored in the GBB somewhere, but we'd have to add a new flag to gbb_utility to extract it. If we had the code to extract this mapping, we could also use that to make the recovery installer screens use the NVRAM locale instead of being forced to the RO_VPD default.

The other question is whether we really want to do this. I think the language changing feature (with the arrow keys) is pretty hard to discover on the firmware screens. You can sort of assume that most people know some English, but if the locale happened to get set to something the user cannot read at all (say Malayan), the recovery screens may be very confusing.

>  we never initialize the NVRAM locale to anything, so it is always English out of the factory.

That is incorrect. We do set that language to match region when leaving factory.
https://chromium.googlesource.com/chromiumos/platform/factory/+/master/py/gooftool/core.py#576

 Issue 857024  has been merged into this issue.

imo, having the recovery image tryi to load lang settings from disk is off the table.  if we can figure out something from vpd/nvram, that sounds reasonable.

do we have a design doc or something to explain locale management in vpd/nvram/stateful ?  the vpd repo documents the vpd format, but not really the meaning of any of its keys.

> do we have a design doc or something to explain locale management in vpd/nvram/stateful

Not that I know of. There used to be some info about the firmware format in the bmpblk README, but it hasn't been updated when everything was overhauled in 2015.

Essentially, 'crossystem loc_idx' can be used to get/set the NVRAM locale index from userspace. It's a uint8_t that corresponds to a locale. 'en' is always 0, but the others are dependent per platform, so you need to check out the translation table in flash. You can get it with

 flashrom -r -i COREBOOT:/tmp/coreboot.bin
 cbfstool /tmp/coreboot.bin extract -n locales -f /tmp/locales

(Reading flash takes time, so this should not be done in a critical path.) The 'locales' file just has one locale code (like 'en') per line and the line number corresponds to the loc_idx in NVRAM (counted from 0).

I'm happy to help with guidance and reviews if somebody wants to implement this, but I have no time to do it myself.

Those were implemented for different purposes.

The vpd, 'region', was hard-coded and can't be changed, as where the device was shipped to.

The loc_index in NVRAM was an alternative since there were easy way for firmware screens to support multiple locales easily.

A consequence is that, there's direct no mapping, or relationship, between VPD (region)  and bmp_idx.

> A consequence is that, there's direct no mapping, or relationship, between VPD (region)  and bmp_idx.

...but there is? It's defined by the locales file in CBFS, see what I wrote in #8. Maybe the locale names there don't match up 100% with the ones used in VPD (do we use 'en' or 'en_US' there?), but with some careful matching logic it shouldn't be too hard to get them to line up.

That is true. You may add some mapping. I'm simply explaining the history and that it may be not easy to find 100% match, for example the number of locales are not the same, and that make the mapping logic more complicated.

Meanwhile I suspect how many people will use arrow keys in firmware screen to change locale to his preference - so this is probably not adding too much help; it seems more reasonable to match the locale set by last Chrome browser.

> Meanwhile I suspect how many people will use arrow keys in firmware screen to change locale to his preference - so this is probably not adding too much help; it seems more reasonable to match the locale set by last Chrome browser.

Yes, but that is not directly accessible in a recovery situation. I guess you could store it in RW_VPD if you wanted, but that wasn't really designed for such frequent updates either.

I think the best thing to do here would be to tie all three together: Chrome locale changes would update NVRAM, and then NVRAM is used by both firmware and recovery installer. I agree that just tying the installer and firmware together alone wouldn't make much sense, but if you sync them all three that might improve the user experience.