Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NVDA installation may fail with an error if system UI language and language for non-unicode programs don't match #5166

Closed
nvaccessAuto opened this issue Jun 20, 2015 · 14 comments · Fixed by #10875
Labels
bug component/i18n p3 Python 3
Milestone

Comments

@nvaccessAuto
Copy link

@nvaccessAuto nvaccessAuto commented Jun 20, 2015

Reported by k_kolev1985 on 2015-06-20 07:56
Hello,

The tests are done on 2 machines with Windows 7 Ultimate 32-bit, but I think that the issue will occur on every version of Windows supported by NVDA, if the conditions are met. In both cases, the UI language was set to "bulgarian", but the language for non-unicode programs was set to something else, witch doesn't support cyrillic (bulgarian) text ("English (United States)" is such a language). In such a case, NVDA will display an error message dialog with the information that the installation failed and for more details to check the NVDA log file. The log file reports an error related to the creation of the NVDA desktop shortcut (see the attached log files). However, the shortcut seams to be created OK - it works as it should, including the Control+Alt+N keyboard shortcut to launch or restart NVDA (it is set in the shortcut's properties). If the UI language and the language for non-unicode programs match, there is no issue. I suspect that the issue will occur only if the language for non-unicode programs set doesn't support displaying of text in the UI language set.

BTW: As far as I know, it is not a common thing for the UI language and the language for non-unicode programs to mismatch on a standard PC configuration (at least the language for non-unicode programs is set correctly). But sometimes (such as in the case mentioned above), it may be set so by mistake. In normal circumstances, we here in Bulgaria set the language for non-unicode programs to "Bulgarian", so we don't have issues with displaying cyrillic text in non-unicode programs.

Steps to reproduce the issue:

  1. In Control Panel -> Region and Language, set the UI language and the language for non-unicode programs to such values, so the language for non-unicode programs will not support displaying of text in the UI language set. Reboot if required.
  2. I'm not sure that it is required, but just to be sure - delete the NVDA shortcut on the desktop.
  3. Start installing or updating NVDA from a downloaded installer.
  4. In the installer, check the option to create a shortcut for NVDA on the desktop.
  5. Wait for the installer to do its job.

Actual results:
NVDA will display an error message dialog with the information that the installation failed and for more details to check the NVDA log file.

Expected results:
The NVDA installation/update should complete with no such errors, even if the UI language and the language for non-unicode programs don't match.

Test environment:

  • Operating system: Windows 7 Ultimate 32-bit.
  • NVDA version: 2015.2.
@nvaccessAuto
Copy link
Author

@nvaccessAuto nvaccessAuto commented Jun 20, 2015

Attachment NVDA_Install_Error_Log_2015-06-12.txt added by k_kolev1985 on 2015-06-20 07:57
Description:
Update:
File added from Trac
NVDA_Install_Error_Log_2015-06-12.txt

@nvaccessAuto
Copy link
Author

@nvaccessAuto nvaccessAuto commented Jun 20, 2015

Attachment NVDA_Install_Error_Log_2015-06-19.txt added by k_kolev1985 on 2015-06-20 07:58
Description:
Update:
File added from Trac
NVDA_Install_Error_Log_2015-06-19.txt

@nvaccessAuto
Copy link
Author

@nvaccessAuto nvaccessAuto commented Jun 22, 2015

Comment 1 by jteh on 2015-06-22 01:59
It's actually creating the website shortcut in the Start Menu that fails. Interestingly, creating the NVDA shortcut in the Start Menu happens before this and works fine. I see we don't pass all strings as Unicode. Python normally just assumes ASCII and converts in this case, but it seems ctypes does something different behind the scenes and I'm not exactly sure what. I'm not certain this is the issue, but it's the best I can come up with. When i get a chance, I'll try using all Unicode paths in a try build and perhaps you can see if that works.

@nvaccessAuto nvaccessAuto added bug component/i18n labels Nov 10, 2015
@jcsteh jcsteh removed their assignment Sep 5, 2017
@Adriani90
Copy link
Collaborator

@Adriani90 Adriani90 commented Jan 29, 2019

@k-kolev1985 I know that this might be difficult to test, but do you think this issue is still occuring? cc: @josephsl

@k-kolev1985
Copy link

@k-kolev1985 k-kolev1985 commented Jan 29, 2019

@Adriani90 Since there hasn't been any work done in order to fix this in NVDA, I doubt that is fixed now. I may be able to test it in one of my virtual machines these days and report the results here. I just need to find some free time to do it. :-)

@k-kolev1985
Copy link

@k-kolev1985 k-kolev1985 commented Feb 2, 2019

@Adriani90 Yes, the bug is still reproducible with latest NVDA alpha snapshot and Windows 10 build 18323 Insider Preview, as described in the first post here. But if I check the beta option to use Unicode UTF-8 for locale support in Windows (under the combobox for selecting the language for non-Unicode programs), the problem does not occur, even if the display/UI language and the language for non-Unicode programs don't match.

@leonardder
Copy link
Collaborator

@leonardder leonardder commented Feb 2, 2019

I assume we can somehow fix this when switching to Python 3.

@leonardder leonardder added p3 Python 3 labels Feb 2, 2019
@leonardder leonardder added this to To do in Update NVDA to Python 3 via automation Feb 2, 2019
@leonardder
Copy link
Collaborator

@leonardder leonardder commented Aug 27, 2019

@k-kolev1985: Could you please test this with an Alpha version of NVDA? I assume it has been fixed implicitly, though if it is fixed, I think it deserves a change log entry.

@k-kolev1985
Copy link

@k-kolev1985 k-kolev1985 commented Aug 27, 2019

I've tested with NVDA snapshot alpha 18450,8c27752f and the error during install still occurred. It wasn't on a clean install of NVDA, but I think that does not matter. The testing is done on Windows 10 (build 18963 I think), 32-bit, in bulgarian, with language for non-Unicode programs set to "English U.S.".

@leonardder
Copy link
Collaborator

@leonardder leonardder commented Aug 27, 2019

@k-kolev1985
Copy link

@k-kolev1985 k-kolev1985 commented Aug 27, 2019

OK, here is the log from the failed installed of the alpha build.
NVDA_Log_2019-08-27_#5166.log

@leonardder
Copy link
Collaborator

@leonardder leonardder commented Sep 4, 2019

This looks like an issue in the WshShell interfaces. When I'm not using dynamic dispatch, the issue seems to be that the path is silently converted to mbcs, any unicode characters get lost and are replaced by a question mark. However, question marks are not allowed in file names, and therefore neither in shortcut names.
We could solved this by encoding to mbcs with errors="ignore" and than decoding back, however, this will cause anything that's not accepted by mbcs to get lost in the process.

@k-kolev1985 Couldn't you set the language for non-unicode programs to Bulgarian instead, or does that cause other issues for you?

@leonardder leonardder removed this from To do in Update NVDA to Python 3 Sep 4, 2019
@k-kolev1985
Copy link

@k-kolev1985 k-kolev1985 commented Sep 4, 2019

@leonardder I don't do that change intentionally. Neither are the other bulgarian Windows users. We know that we should set the language for non-unicode programs to "Bulgarian" for best results. But by mistake it may happen. Once, I was configuring a new virtual machine with Windows 10 and I forgot to set the language for non-unicode programs to "Bulgarian" and had to deal with problems with text in cyrillic not displaying correctly in non-unicode programs and text files, before I realized my mistake. Recently it happened to a friend of mine - he forgot to set the language for non-unicode programs to "Bulgarian" and got the same error during install of NVDA. So, such configuration is not intentional, but by mistake. I don't know of cases in which is/was required to set the language for non-unicode programs to something other than "Bulgarian" for some purposes, but there may be such cases - it wouldn't surprise me.

@jcsteh
Copy link
Contributor

@jcsteh jcsteh commented Sep 4, 2019

We've seen this problem before in #6326. Although this was reported as fixed in #6326 (comment), I don't think the underlying problem was really fixed. Perhaps the localisation worked around it or the user changed system settings.

I did a pretty in-depth analysis of this and provided a possible solution in #6326 (comment) . Including it below since that issue is now closed.

It looks like this happens for any character that can't be encoded using the system ANSI code page:

>>> u"\u2022".encode("mbcs")
'\x95'
>>> u"ț".encode("mbcs")
'?'
>>> u"‣".encode("mbcs")
'?'

If I try creating the shortcut with either of the latter two, I get an exception.

Even though we pass the string as Unicode, wScript.Shell seems to convert it to ANSI. It seems others have hit this problem too. Note that this is definitely not a file system issue; you can quite happily write a file containing these characters if you use native Unicode:

>>> file(u"c:\\users\\jamie\\junk\\jtd‣bar", "w")
<open file u'c:\\users\\jamie\\junk\\jtd\u2023bar', mode 'w' at 0x070573E8>

I wonder whether we'll need to switch to an alternative way of creating these shortcuts. We should be able to do this using IShellLink and friends. IShellLink specifically mentions IShellLinkA and IShellLinkW interfaces, which suggests the latter does explicitly do Unicode. See this article for further details. I did a bit of investigation on this in the labyrinth that is MSDN:

  1. I found CLSID_ShellLink in ShObjIdl.idl (00021401-0000-0000-C000-000000000046). Unfortunately, it looks like there's no typelib registered for this.
  2. There are also dispatch interfaces for most (all?) of this stuff. You access them by using the "shell.application" progId. See Scriptable Shell Objects and ShellLinkObject.Save for details/examples.

feerrenrut added a commit that referenced this issue Mar 17, 2020
Partial fix for #5166 #6326

Some unicode characters can not be used by the wsh API to create a shortcut. Sometimes translations contain these characters causing an error during installation.
Mitigate this issue by wrapping each call to create shortcut in a try block, on error try to create the shortcut without translation.
@nvaccessAuto nvaccessAuto added this to the 2020.1 milestone Mar 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug component/i18n p3 Python 3
Projects
None yet
5 participants