You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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_slavegettext and pgettext are no longer installed before initializing languageHandler.
Testing strategy:
Made sure NVDA starts - this require a longer period of testing in Alpha anyway.
Known issues with pull request:
None known
Change log entries:
None needed - this has no impact for add-ons developers since add-ons were initialized after languageHandler.
Code Review Checklist:
Pull Request description:
description is up to date
change log entries
Testing:
Unit tests
System (end to end) tests
Manual testing
API is compatible with existing add-ons.
Documentation:
User Documentation
Developer / Technical Documentation
Context sensitive help for GUI changes
UX of all users considered:
Speech
Braille
Low Vision
Different web browsers
Localization in other languages / culture than English
What about keeping these functions as a fallback but logging an error instead (log.error)? This would allow to avoid NVDA not starting at all in case such error is encountered.
Of course, the log should be delayed in some way because the log handler may not be initialized when the fake translation (or rather fallback translation) is called.
What about keeping these functions as a fallback but logging an error instead (log.error)? This would allow to avoid NVDA not starting at all in case such error is encountered.
Of course, the log should be delayed in some way because the log handler may not be initialized when the fake translation (or rather fallback translation) is called.
This would add quite a lot of complexity for very little benefit IMHO.
I see three scenarios worth considering for this work:
When implementing a new feature developer mistakenly imports a module with localized variables at the top level before initializing translations - in that case NVDA failing to start rather than logging an error is a good thing.
In some scenario which we haven't tested before merging this PR NVDA imports a module with translatable variables - if it fails in Alpha NVDA failing to start is an acceptable outcome and users tent to ignore errors in the log anyway.
For stable NVDA errors in the log aren't visible for most users, - while NVDA failing to start is not ideal we would at least know that something has failed.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Link to issue number:
Related to #14660
Summary of the issue:
When starting NVDA installs a 'fake'
gettextandpgettextfunctions 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 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_slavegettextandpgettextare no longer installed before initializinglanguageHandler.Testing strategy:
Made sure NVDA starts - this require a longer period of testing in Alpha anyway.
Known issues with pull request:
None known
Change log entries:
None needed - this has no impact for add-ons developers since add-ons were initialized after
languageHandler.Code Review Checklist: