-
-
Notifications
You must be signed in to change notification settings - Fork 652
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
Comments
Comment 1 by mdcurran on 2012-08-10 23:02 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''' |
Comment 2 by nvdakor on 2012-08-11 04:13 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. |
Comment 3 by briang1 on 2012-08-11 07:59 Varnish cache server |
Comment 4 by jteh on 2012-08-11 11:45 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. :) |
Comment 5 by briang1 on 2012-08-11 13:02 Just successfully downloaded the latest snap via the updater |
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.
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.
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.
The text was updated successfully, but these errors were encountered: