Update liblouis to 3.24.0

[AAClause]

Link to issue number:

None

Summary of the issue:

Liblouis 3.24.0 has been released.

Description of user facing changes

Updates liblouis to 3.24.0 which adds new braille tables. Changelog.

Description of development approach

Update liblouis submodule and make new braille tables available from the NVDA settings.

Testing strategy:

Ran from sources and loaded new braille tables. LGTM.

Known issues with pull request:

None

Change log entries:

Section: Changes

- Updated liblouis braille translator to [3.24.0 https://github.com/liblouis/liblouis/releases/tag/v3.24.0]. (#14436)
  - Major updates to Hungarian, UEB, and Chinese bopomofo braille.
  - Support for the Danish braille standard 2022.
  - New braille tables for Georgian literary braille, Swahili (Kenya) and Chichewa (Malawi).

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
• Security precautions taken.

[AppVeyorBot]

• PASS: Translation comments check.
• PASS: Unit tests.
• PASS: Lint check.
• FAIL: System tests (tags: installer NVDA). See test results for more information.
• Build (for testing PR): https://ci.appveyor.com/api/buildjobs/2g0fegxcaep6y32w/artifacts/output/nvda_snapshot_pr14436-27257,a936a4a0.exe
• CI timing (mins):
  INIT 0.0,
  INSTALL_START 0.9,
  INSTALL_END 0.8,
  BUILD_START 0.0,
  BUILD_END 23.3,
  TESTSETUP_START 0.0,
  TESTSETUP_END 0.3,
  TEST_START 0.0,
  TEST_END 19.6,
  FINISH_END 0.1

See test results for failed build of commit a936a4a0ba

[LeonarddeR]

Could you please remove the following lines from nvdaHelper/liblouis/sconscript?

# Starting from Clang 15, the -Wint-conversion warning diagnostic for implicit int <-> pointer conversions
# now defaults to an error in all C language modes.
# Downgrade this to a warning so we can still build.
env.Append(CCFLAGS='-Wno-error=int-conversion')

This was fixed in liblouis/liblouis#1263 and is therefore no longer necessary.

[AAClause]

Questions:

1. Since the following braille tables were previously not usable from NVDA:
   "da-dk-g26l.ctb", "da-dk-g28l.ctb", "da-dk-g26l-lit.ctb"
   Should we make available the following renamed braille tables?:
   "da-dk-g26l_1993.ctb", "da-dk-g28l_1993.ctb", "da-dk-g26l-lit_1993.ctb"

2. Instead of this:

   addTable("da-dk-g28_1993.ctb", _("Danish 8 dot grade 2 (1993)"), contracted=True)
   addTable("da-dk-g28.ctb", _("Danish 8 dot grade 2 (2022)"), contracted=True)
   

   What do you think of that?:

   addTable("da-dk-g28_1993.ctb", _("Danish 8 dot grade 2") + " (1993)", contracted=True)
   addTable("da-dk-g28.ctb", _("Danish 8 dot grade 2") + " (2022)", contracted=True)
   

   This would save translators time.

[zstanecic]

Hi, I am voting here as one of the translators: It doesn’t make a difference, because users should have access both to the new and old standard. The example is Korean. As I recall, Korean has pre 2006 and after 2006 standard, and both braille tables, as wel as g1 and g2 are available. So, why to make here exception or difference? The Danish people, who are used to old standard, should have access to it, as well as to the new one. By the way, why we need to specify braille tables manually every release of liblouis? Why we cannot use metadata and get rid of this shame? From: André-Abush Clause ***@***.***> Sent: Monday, December 12, 2022 7:07 PM To: nvaccess/nvda ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [nvaccess/nvda] Update liblouis to 3.24.0 (PR #14436) Questions: 1. Since the following braille tables were previously not usable from NVDA: "da-dk-g26l.ctb", "da-dk-g28l.ctb", "da-dk-g26l-lit.ctb" Should we make available the following renamed braille tables? "da-dk-g26l_1993.ctb", "da-dk-g28l_1993.ctb", "da-dk-g26l-lit_1993.ctb" 2. Instead of this: addTable("da-dk-g28_1993.ctb", _("Danish 8 dot grade 2 (1993)"), contracted=True) addTable("da-dk-g28.ctb", _("Danish 8 dot grade 2 (2022)"), contracted=True) What do you think of that?: addTable("da-dk-g28_1993.ctb", _("Danish 8 dot grade 2") + " (1993)", contracted=True) addTable("da-dk-g28.ctb", _("Danish 8 dot grade 2") + " (2022)", contracted=True) This would save translators time. — Reply to this email directly, view it on GitHub <#14436 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACVCDE5AXGMWLW3JOL22CZ3WM5STRANCNFSM6AAAAAAS23WHIY> . You are receiving this because you are subscribed to this thread. <https://github.com/notifications/beacon/ACVCDEYUM5JJ2TTBUGG32NLWM5STRA5CNFSM6AAAAAAS23WHI2WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSQJEWDQ.gif> Message ID: ***@***.*** ***@***.***> >

[seanbudd]

Is there anything NVAccess needs to do or decide to unstick this PR?

[AAClause]

@seanbudd Sorry, I forgot the PR. I'll fix the last details and request the review.

@zstanecic So you suggest the following display names, right?

• Danish 8 dot grade 1
• Danish 8 dot grade 1 (1993)
• Danish 8 dot grade 2
• Danish 8 dot grade 2 (1993)
• Etc.

Instead of:

• Danish 8 dot grade 1 (2022)
• Danish 8 dot grade 1 (1993)
• Danish 8 dot grade 2 (2022)
• Danish 8 dot grade 2 (1993)
• Etc.

Being uniform with Korean tables makes sense to me :)

[zstanecic]

Hi Andre! Yes, i suggest exactly the solution you provided, First instead of second.

[zstanecic]

So, it will be good to have tables named like this: • Danish 8 dot grade 1 • Danish 8 dot grade 1 (1993) • Danish 8 dot grade 2 • Danish 8 dot grade 2 (1993)

[seanbudd]

Either option seems fine to me

[AppVeyorBot]

• PASS: Translation comments check.
• PASS: Unit tests.
• PASS: Lint check.
• FAIL: System tests (tags: installer NVDA). See test results for more information.
• Build (for testing PR): https://ci.appveyor.com/api/buildjobs/31r6e24mu501x1cb/artifacts/output/nvda_snapshot_pr14436-27434,9afe3b2e.exe
• CI timing (mins):
  INIT 0.0,
  INSTALL_START 0.9,
  INSTALL_END 1.0,
  BUILD_START 0.0,
  BUILD_END 27.5,
  TESTSETUP_START 0.0,
  TESTSETUP_END 0.3,
  TEST_START 0.0,
  TEST_END 23.4,
  FINISH_END 0.1

See test results for failed build of commit 9afe3b2ed0