That means you create a config file for each language with the variables title, baseurl, theme and a locale. Then your shell script iterates over each language specific config file, Hugo searches the defined locale of the current config file and uses the corresponding translation to render the page, right?
For those who are interested: the scheme described above (and in the upcoming tutorial) was used by @RickCogley to translate his company site. His repository should be a good example.
Basically yes but it just a single config file load per zsh function, not iterating over them all, though, that would be a good way to do this, in the case of many languages.
See
So the hiearchy goes from right to left, more specific to less, the fallback is messages.yaml (or toml, json).
All this seems like an elegant way to do it. But I don’t understand so well what you mean by hierarchy … from right to left, or how that might be implemented.
One thing that I’ve been thinking about, and I think what you’re referring to, is the suffixes for language and locale, eg. *_en, *_en-US, *_en-GB, *_es, *_es-ES… etc. It would be nice, for example for it not to matter so much if someone asks for *_es-AR and in the case where there isn’t one, it defaults to _es.toml
Hope that makes sense.