Add support for custom braille translation tables

[josephsl]

Hi,

With nvaccess/nvda#3304 implemented (NVDA 2024.3), it becomes possible to define and include custom braille translation tables as an add-on or included with other add-ons. With this, an add-on author can ship a Liblouis compatible braille table.

The manifest format resembles nested dictionaries:

• A key named "brailleTables" houses custom braille translation tables.
• Each custom table is a key within the dictionary, with file name as the key.
• The braille table (key) entry has four fields: displayName (description), contracted (contracted (True) or uncontracted (False) braille code), input (available from input table list), output (shown in output table list).

The challenge here is allowing localized display name for braille tables - this is no longer a top-level manifest key, so manifest translation template must be edited.

Thanks (NVDA feature implementation by @leonardDeR).

[LeonarddeR]

Ugh, thanks for opening this. We probably should have thought about this before. What would be your suggestion to make the display names translatable programmatically? We somehow need to store the table names in gettext strings to work correctly. May be add a customBrailleTables.py file to the root of the template that allows you to define your custom tables, and then the build system should construct the manifest section from that file and the translated manifest should be created accordingly.

[josephsl]

Hi, I’m looking at adding a dedicated “brailleTables” dictionary in buildVars.py which can be picked up by sconstruct. The add-on (custom braille tables) name can be retrieved from addon_info dictionary, so the issue comes down to how to pick up table display names and get them ready for translations. I think the custom Python file sounds fine, but I think keeping them under one roof/file would make the repos more organized. I think we should open a companion issue on NVDA Core repo if you think NVDA itself should be involved somehow. Thanks.

[LeonarddeR]

I'm not sure how NVDA itself should be involved. It has been endlessly discussed that we needed a familiar way to save the meta data, and the manifest seemed to be the most obvious place. Given that the add-on template is responsible for creating manifests, it should also be able to create table entries.

A tables dictionary in buildVars makes sense. I'd support two options:

1. Table filename as key and translatable display name as value, keeping all other entries (e.g. contracted, input) to their default
2. Table filename as key and dictionary as value, where the dictionary simply mimics the manifest format

[josephsl]

Hi,

I have implemented the second option (full manifest) to present the same feel as root manifest section a.k.a. buildVars.addon_info dictionary. The trick I am employing is that the braille tables dictionary must have at least one entry, otherwise custom braille table portion of manifest generation is skipped. I'm testing these modifications with Windows App Essentials add-on before bringing it to the template repo.

I'll release custom braille tables support as part of template 2024.2 this week and label it as experimental - full support won't be provided until NVDA Core 2024.3 beta 1 is released.

Thanks.