feat: Language in config file #1493
Conversation
| @@ -192,6 +192,9 @@ class Config(configfile.ConfigFileWithProfiles): | |||
| PLUGIN_MANAGER = pluginmanager.PluginManager() | |||
|
|
|||
| def __init__(self, config_path=None, data_path=None): | |||
| # Note: The main profiles name here is translated using the systems | |||
| # current locale because the language code in the config file wasn't | |||
| # read yet. | |||
| configfile.ConfigFileWithProfiles.__init__(self, _('Main profile')) | |||
There was a problem hiding this comment.
In the future we should remove the ability to translate the first profiles name. A name as an identifier shouldn't be translated at all. Related to #1371
There was a problem hiding this comment.
or even better: Why do we need a default profile at all?
|
I did not yet deep dive into the change set but AFAIR changing the config file format (here: by adding a new entry) requires to increment the config file version in I couldn't see this in the change set (and this also possibly requires to update the config file format of unit test configs to avoid an unexpected output that fails some unit tests)... |
I'm aware of that version variable but I I don't see a need to increment it. Adding a new variable do not "change the format". It do not break existing behavior. And the variable do not need to be present in the config file because there is a default value for it. Technically there is no need to update old config files if you do not modify the name or format of existing variables. If the line |
I think reusing the new config format with an older BiT version will no longer work (though I am not sure if this is a use case). Anyhow I think it would be more clean to increment the config file version every time we change the format (even though it is non-destructive/additive). I am not sure how Germar handled this in the past, perhaps browsing the change history of the version could help. |
It is an unusual case but possible. I'll test that. But I'm quit deep into the code of
I don't think it is clean to even have a version number for config formats. That is my problem with the solution. I don't see a need for such a version number. There are other ways to handle modifications of variable names and similar things in a config file. |
I added two lines to my BIT 1.3.3 config file. No problem. I can read all snapshot profiles and also modify them. That two lines are still in the config file. |
| @@ -192,6 +192,9 @@ class Config(configfile.ConfigFileWithProfiles): | |||
| PLUGIN_MANAGER = pluginmanager.PluginManager() | |||
|
|
|||
| def __init__(self, config_path=None, data_path=None): | |||
| # Note: The main profiles name here is translated using the systems | |||
| # current locale because the language code in the config file wasn't | |||
| # read yet. | |||
| configfile.ConfigFileWithProfiles.__init__(self, _('Main profile')) | |||
There was a problem hiding this comment.
or even better: Why do we need a default profile at all?
New key "global.language" in config file to customize the UI language.
Language codes are used as values. If empty (or key not present) the systems current locale is used. If "en" or unknown the sources strings (in English) are used as fallback.
No matter that it hurt me I decided against creating a unit test for "global.language" config value. I have a refactoring about the config-file handling in my mind which will ease up a lot of things including unit testing.