Problem description
When starting NVDA installs a 'fake' gettext and pgettext functions which translates to the language set as the current Windows locale. Later in the startup process languageHandler overwrites these installed translation functions with a new one which translate strings to the language chosen by the user (either in the configuration or from the CLI). Unfortunately if there is a module with translatable strings at its top level and it is imported before languageHandler is initialized these strings are either translated to the default system language, or for locales for which Python's locale.getdefaultlocale fails they remain in English. Similar problems were reported in #7770 and in #14657. Both of these are fixed, but the main problem here is that bugs like this are difficult to identify before the release, since most contributors either use both NVDA and Windows in English, or at least their NVDA is in the same language as their operating system.
Describe the solution you'd like
NVDA should not install any translation functions before initializing languageHandler. While this means we would have to be possibly more careful with imports at least if someone imports a module with translatable strings before language is initialized they would get a clear failure rather than, as it is now, no sign that something went wrong.
In the long term it would also be nice not to install a fake gettext in unit tests before initializing language, and move all non-localizable build information from versionInfo to buildVersion so that initializing gettext would not be necessary when accessing version information during build.
Describe alternatives you've considered
Leave code as is.
Problem description
When starting NVDA installs a 'fake' gettext and
pgettextfunctions which translates to the language set as the current Windows locale. Later in the startup processlanguageHandleroverwrites these installed translation functions with a new one which translate strings to the language chosen by the user (either in the configuration or from the CLI). Unfortunately if there is a module with translatable strings at its top level and it is imported beforelanguageHandleris initialized these strings are either translated to the default system language, or for locales for which Python'slocale.getdefaultlocalefails they remain in English. Similar problems were reported in #7770 and in #14657. Both of these are fixed, but the main problem here is that bugs like this are difficult to identify before the release, since most contributors either use both NVDA and Windows in English, or at least their NVDA is in the same language as their operating system.Describe the solution you'd like
NVDA should not install any translation functions before initializing
languageHandler. While this means we would have to be possibly more careful with imports at least if someone imports a module with translatable strings before language is initialized they would get a clear failure rather than, as it is now, no sign that something went wrong.In the long term it would also be nice not to install a fake gettext in unit tests before initializing language, and move all non-localizable build information from
versionInfotobuildVersionso that initializing gettext would not be necessary when accessing version information during build.Describe alternatives you've considered
Leave code as is.