nvda

f8783563 - Store current NVDA's language in globalVars regardless if it has been provided from the command line or not. (#13082)

Store current NVDA's language in globalVars regardless if it has been provided from the command line or not. (#13082) Follow up of #10089 and #12958 Summary of the issue: PR #12958 introduced additional command line parameter which allows to set NVDA's language. The currently set language is stored in globalVars.appArgs.language however when it is not overridden from the CLI this variable is set to None. TO improve consistency with globalVars.appArgs.configPath it makes sense to store current NVDA's language in globalVars regardless of where it comes from. Description of how this pull request fixes the issue: Current NVDA language is now stored in globalVars.appArgs.language - it still can be accessed via languageHandler.getLanguage which is a recommended way to get its value for add-ons developers. To make this work for nvda_slave it has been necessary to provide a 'fake' implementation of globalVars.appArgs which is used in cases where command line arguments are not available or not yet parsed. This also provides type hints for values of appArgs so I'd say it is beneficial regardless. * Use `languageHandler.getLanguage` when querying current NVDA's language rather than accessing `curLang` directly. * Store current NVDA's language in `globalVars` * Set `globalVarrs.appArgs` to a fake implementation by default. * update changes Co-authored-by: buddsean <sean@nvaccess.org>