Short scale is only for insecure rich people who need to feel even richer than they already are. It should be abolished!
**Ducks from all the Americans**

But back to the real issue. Would an example be en_AU where technically the long scale is officially correct, but many people use the short scale because of TV (or something)?

Would this need to be changed on the fly or only when a language is loaded? Presumably this would override the normal default for each method, but if it's intentionally passed in a method call then the Skill (or code) that called it can override the user defined config? eg:

1. lang default
2. user config
3. method call
   ?

en_AU and the number scale is a perfect example!

I think the goal is to make it changeable at runtime, but we don't need to get fancy with the data structures. Just provide some getters and setters so that the implementation can fix things up from its config files.

lingua_franca.config.set_number_scale('en_AU', 'short')

In practice, I figure (for example) that Mycroft would call those functions when it imports LF, shortly after loading languages. Some kind of for loop over the relevant config values.

I saw another FOSS assistant project, with some familiar faces ❤️, eyeing Lingua Franca. I don't know if they actually adopted us, but, if so, their config files will surely look different from Mycroft's; as long as we stick to get/sets, that won't matter to LF!

And, probably goes without saying, if Mycroft has an intent to fine-tune settings like that, it can just call the same get/setters. After the refactor, depending how we implement the logic, this might, at most, require a quick LF refresh. Probably not.

My thinking throughout all of this is that, no matter how bloated the resource files become, LF should at worst become part of the same progress bar that loads and unloads language modules in a complex project. Switching your Name Brand voice assistant to another language takes up to a few minutes, between the voice models, hotwords, offline vocab, and other stuff that has to load. I'd like implementations to be able to stick us right in that loop without thinking about it.

i think this is a great idea

On reflection, probably lingua_franca.config.set('en_AU', 'number_scale', 'short'), or else something dict-based, so that it can be read from JSON or YAML in a sane fashion. It might be burdensome to have a function per config value.

Yeah good plan, personally I'd be opting for the dict based:

lingua_franca.config.set('en_AU', {'number_scale': 'short'})

Then any number of attributes can be passed in. Also like that the relationship between key and value is explicit rather than implicit.

Discovered: Mycroft is currently wrapping extract_datetime() to pass the user's configured time zone. That's one setting that ought to be exposed so it can be set here.

I think one good metric here might be replacing downstream wrappers with downstream .set() calls.

Recently identified candidates for config settings:

• timezone
• number format (fraction/decimal/scientific)

Consider a decorator enabling e.g. skill authors to ensure certain defaults for snippets of code, then return LF settings to their original state.

That is, decorate a function to specify decimal numbers, and LF is reconfigured to use decimal numbers by default for the duration of the decorated function. Use context in the decorator to ensure that LF settings go back to their initial state afterward. This way, skill authors will be able to fine-tune output even when LF has been abstracted away.