Do you use #eloquence on the 64-bit #nvda#screenreader? If so, a new release is available, and we could use your help! You can find out more info on the release page: github.com/fastfinge/eloquence_64/releases/tag/v4#blind#accessibility#a11y
Release v4: A Lot Of Good Volunteers · fastfinge/eloquence_64
As with any open source project, 64-bit eloquence wouldn't be possible without the community behind it. This release brings us the following: fixes to indexes, and further code simplification (Tha...GitHub
reshared this
James Scholes
in reply to 🇨🇦Samuel Proulx🇨🇦 • • •To localise the settings panel: import `addonHandler`, call `addonHandler.initTranslation()`, and then wrap all user-facing labels (e.g. text of checkboxes) in a call to the magic underscore (`_`) function.
E.g. `_('&Maximum number of history entries (requires NVDA restart to take effect)')`
🇨🇦Samuel Proulx🇨🇦
in reply to James Scholes • • •🇨🇦Samuel Proulx🇨🇦
in reply to James Scholes • • •James Scholes
in reply to 🇨🇦Samuel Proulx🇨🇦 • • •No, but I did forget one thing: you should put a `# Translators: ...` comment on the line above where some user-facing text is used for the first time, explaining what that text is for. E.g.:
`# Translators: the label for the button to update community dictionaries from GitHub`
🇨🇦Samuel Proulx🇨🇦
in reply to James Scholes • • •James Scholes
in reply to 🇨🇦Samuel Proulx🇨🇦 • • •Ah... well: there is a translation workflow which will pull the translatable strings out of your add-on, put them somewhere for translators to translate, and then push the locale files back into your add-on. What I'm unsure about is whether they'd accept Eloquence as an add-on in that system.
The details are here:
github.com/nvaccess/mrconfig/b…
mrconfig/readme.md at master · nvaccess/mrconfig
GitHub🇨🇦Samuel Proulx🇨🇦
in reply to James Scholes • • •James Scholes
in reply to 🇨🇦Samuel Proulx🇨🇦 • • •Indeed. Probably easiest to have people clone the repo, pull out the translatable strings into a file using an appropriate tool (or do that yourself and commit it), compile their own translated strings file, and contribute the textual and compiled versions in a PR.
Even though you're not using the add-on template, you can probably reuse the translation-related utilities from it.
github.com/nvaccess/addonTempl…
GitHub - nvaccess/AddonTemplate: Template and metadata used by NVDA community add-ons
GitHub🇨🇦Samuel Proulx🇨🇦
in reply to James Scholes • • •James Scholes
in reply to 🇨🇦Samuel Proulx🇨🇦 • • •You don't really need to test the translations themselves; string selection happens via well trodden code paths inside NVDA. As long as the files end up in the right places (which are documented), it will work.
But I agree with your wider point about the rest of it. I would start by at least making sure the code is set up in the ways I described if it isn't already, because there'll be no translation at all without those bits. And then hope someone can come along to fill in the rest.
🇨🇦Samuel Proulx🇨🇦
in reply to James Scholes • • •James Scholes
in reply to 🇨🇦Samuel Proulx🇨🇦 • • •🇨🇦Samuel Proulx🇨🇦
in reply to James Scholes • • •James Scholes
in reply to 🇨🇦Samuel Proulx🇨🇦 • • •Don't tell anyone, but localisation is one reason I don't like working on software for the community. Not because I don't think it's critical; obviously people should have the thing available in their language.
But the common tools are just so... hacky. They feel like they were built with an order of priorities that went developer, translator, user, when I think user and translator should be considered as far more important.
As a result, the developer experience isn't actually that great—relying on magic global state and functions as it does—and translations can end up with anglicised word ordering because the English-speaking developers and tools get in the way.
🇨🇦Samuel Proulx🇨🇦
in reply to James Scholes • • •🇨🇦Samuel Proulx🇨🇦
in reply to James Scholes • • •