Yes I noticed that too but ...
-what happens if Sigil's list of UI languages gets longer aren't we back to the original problem?
- anyone advanced enough to use this environment var to restrict language codes should include their ui language code, shouldn't they? None of the others ui codes should matter as their code is there just not the translations..
And fwiw instead of merging, a simpler solution might be to check if a data item is in ui language list codes OR in the user code when user codes are specified. That saves building a merged list and that extra routine.
So I am not sure this is something to worry about, but if you feel strongly, then please create a PR using the OR approach and I will merge it.
Thanks!
Quote:
Originally Posted by BeckyEbook
@KevinH: I would like to return to the issue SIGIL_ONLY_USE_LANGCODES described in post #120.
The current implementation has a side effect, which is that the UI language list is missing information, because when we limit the list of languages, it is done globally – for the entire Sigil.
Screenshot:
Attachment 218666
So I suggest partially incorporating Doitsu's latest suggestion from post #6 and meeting halfway: let's add at least those languages that have translations for the Sigil interface to the list of languages declared in the environment variable.
I have a working solution that you can certainly optimize.
The result is an expanded list of languages, which of course also appears in the metadata editing window:
Attachment 218667
Attachment 218668
I already have an updated EnvVarEditor plugin that supports the new environment variable, but I want to test it a little more before the official release. The language validation function will not allow duplicates or incorrectly written language codes. IMVHO – it works great  and really makes my life easier.
Attachment 218669 |