Installation of dummy gettext and pgettext functions before initialization of languageHandler can cause hard to track bugs #14660
Labels
audience/nvda-dev
PR or issue is relevant to NVDA / Add-on developers
merge-early
Merge Early in a developer cycle
p5
https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority
triaged
Has been triaged, issue is waiting for implementation.
Comments
|
@michaelDCurran Would you accept a PR targeting 2023.2 for the first part of this issue i.e. no longer installing |
6 tasks
seanbudd
added
audience/nvda-dev
|
@lukaszgo1 please go ahead |
6 tasks
seanbudd
pushed a commit
that referenced
this issue
Mar 2, 2023
#14677) Related to #14660 Summary of the issue: 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 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. Description of user facing changes This should not have any user visible impact. Description of development approach When starting NVDA or nvda_slave gettext and pgettext are no longer installed before initializing languageHandler.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The text was updated successfully, but these errors were encountered: