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 development snapshots appears to be frozen #2592

Closed
nvaccessAuto opened this issue Aug 10, 2012 · 5 comments
Closed

NVDA development snapshots appears to be frozen #2592

nvaccessAuto opened this issue Aug 10, 2012 · 5 comments

Comments

@nvaccessAuto
Copy link

Reported by nvdakor on 2012-08-10 21:28
Hi,
Since Tuesday (August 7th), the NvDA Snapshots page does not show newly changed versions. The latest main snapshot is 5320, while at the time of this writing, it is up to 5334. Thanks.

@nvaccessAuto
Copy link
Author

Comment 1 by mdcurran on 2012-08-10 23:02
Technical info:
Seems snapshots have been failing since seika.py was committed. It  is because scons pot is not successful.

Exgettext complains about lines 51 and 80 and possibly 82 and it says to please specify the source encoding.

These strings have raw hex codes in them, and  it is true that they would not be ascii characters. But, I would have thought we would have had other braille display drivers with similar byte strings?

I have no idea how this scould be fixed. Why would exgettext try to parse those strings even though they're not inside a _()?

Tried things like b"blahblah" and b'''blahblahblah'''
But it keeps finding them.

@nvaccessAuto
Copy link
Author

Comment 2 by nvdakor on 2012-08-11 04:13
Doing some investigations by comparing various braille py files and googling this issue. But to make sure: you could have tried this, but have you tried compiling without seika.py? If the code compiles, then it is formatting issue with that driver init/cell count detection function.

According to some Google searches, this would have occured if gettext interpreted the string as a pure unicode text. Some search results advised people with this issue to use latest version of gettext.

@nvaccessAuto
Copy link
Author

Comment 3 by briang1 on 2012-08-11 07:59
Actually the first I knew about the lack of updates was when it failed with an error and I posted the snap page text at that time in the dev list, that seemed to be a Sourceforge issue. so it may well be true that snaps won't compile, but it may well have been just a
coincidence that I got this!
There will very possibly be nasty bugs and broken code, and we will not
provide any support for these snapshots. Constructive feedback is
nevertheless welcome.
Error 503 Service Unavailable
Service Unavailable
Guru Meditation:
XID: 731290822

Varnish cache server
Start Page

@nvaccessAuto
Copy link
Author

Comment 4 by jteh on 2012-08-11 11:45
This extraction of strings not marked as translatable is a reported bug in gettext: http://savannah.gnu.org/bugs/?30558

I've worked around this by declaring an encoding of UTF-8 for seika.py, even though there are no real UTF-8 strings. :) This is what Mesar did for baum.py, almost certainly for the same reason. brailliantB.py also contains raw hex strings, but they're all within the ASCII range.

Fixed in fed61e9.

Btw, Brian, the web server issue and this issue happening at around the same time is purely coincidence. One of the reasons i didn't look into this sooner is that after your message, I initially assumed it was just SourceForge web server weirdness. :)
Changes:
Milestone changed from None to 2012.3
State: closed

@nvaccessAuto
Copy link
Author

Comment 5 by briang1 on 2012-08-11 13:02
Yes, that was my thought also, which is why I did not ticket it.

Just successfully downloaded the latest snap via the updater

@nvaccessAuto nvaccessAuto added this to the 2012.3 milestone Nov 10, 2015
jcsteh added a commit that referenced this issue Jul 20, 2017
The superBrl braille display driver includes escape sequences which produce non-ASCII characters; e.g. "\xff". Due to a gettext bug, this causes xgettext to fail even though these aren't in translatable strings. See #2592 (comment).

1. To work around this, declare encoding as UTF-8 for the superBrl driver.
2. Make AppVeyor build the translation template so that builds fail for problems like this. This way, we learn about such problems long before they get to the translation system.
3. Explicitly exclude source\comInterfaces for scons pot to avoid unknown encoding warnings. These files never contain translatable strings anyway.
jcsteh added a commit that referenced this issue Jul 20, 2017
The superBrl braille display driver includes escape sequences which produce non-ASCII characters; e.g. "\xff". Due to a gettext bug, this causes xgettext to fail even though these aren't in translatable strings. See #2592 (comment).

1. To work around this, declare encoding as UTF-8 for the superBrl driver.
2. Make AppVeyor build the translation template so that builds fail for problems like this. This way, we learn about such problems long before they get to the translation system.
3. Explicitly exclude source\comInterfaces for scons pot to avoid unknown encoding warnings. These files never contain translatable strings anyway.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant