Clarify / fix the list of supported languages

[CyrilleB79]

Steps to reproduce

1. Since the recent inclusion of Cambodian / Khmer, the language list contains 66 items. If you remove default user and English, 64 items are remaining. Though, the User Guide indicates that NVDA is translated in 56 languages. This is not consistent.

2. In the UG, we indicate that NVDA is translated to "Chinese (simplified and traditional)", but for traditional, there is no indication that both translations to Taïwan and Hong-Kong traditional Chinese exist in NVDA.

3. In the list of existing NVDA translation in the UG, we indicate "Norwegian", but do not specify that both Bokmål and Nynorsk versions exist. On the contrary, we indicate e.g. "German (Germany and Switzerland)".

4. The following languages appear in the language list in NVDA's general settings, but not in the list of translated languages in the User Guide: Bangla (bn), Indonesian (id), Central Kurdish (ckb), Northern Kurdish (kmr), Urdu (ur), Somali (so).

5. Bangla is in the list of possible language in the GUI, but its translation is at 0%; there were twi volunteers at the time, but both of them have withdrawn this job. FWIK, there isn't anybody currently working on Bangla now.

6. Many other languages have a very low coverage (I just look at the interface): Indonesian (10% of translatable strings), Somali (22%), Urdu (6%), Albanese (15%), Afrikaans (13%), Norwegian Nynorsk (20%), etc. The list is not exhaustive.

Actual behavior

We claim that NVDA is translated in many languages but some translations are very ppoor.

Expected behavior

We'd better claim a bit less languages but show a minimal support.

1., 2., 3. and 4. We should end-up with the list in the User Guide and in the GUI being consistent. Alternatively, we may not list all the languages in the User Guide and just say "many languages".

5. Until there are new translators, Bangla should be removed.

6. Now we are quite careful to integrate new languages in the GUI when they have reached a percentage high enough (e.g. 70% or 80%). This has not been respected in the past for various reasons. There may also be languages that have been correctly translated in the past but that need a new volunteer. We should be able to remove languages with a too low perscentage of translation from the GUI, e.g. less than 40%. When the translations percentage of a language decreases below some thresholds (e.g. 70%, 60%, 50%), we should also warn translators about it on the mailing list so that they be aware of that.

NVDA logs, crash dumps and other attachments

N/A

System configuration

NVDA installed/portable/running from source

N/A

NVDA version

Last alpha (nvda_snapshot_alpha-54186,cd0342e0)

Windows version

N/A

Name and version of other software in use when reproducing the issue

N/A

Other information about your system

N/A

Other questions

Does the issue still occur after restarting your computer?

N/A

Have you tried any other versions of NVDA? If so, please report their behaviors

N/A

If NVDA add-ons are disabled, is your problem still occurring?

N/A

Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

N/A

[josephsl]

Hi,

A few things:

• Languages list: some are dialects or variations such as central and northern Kurdish and Portuguese spoken in Portugal and/or Brazil. In the user guide, we should group them properly unless translators say otherwise, and edit the languages overview sentence to say "55 languages (including variants)".
• State of languages: yes, several languages haven't had updates for some time. Complicating matters is that we are no longer using Subversion/Assembla for localization work - Crowdin is used instead, and not all translators are used to the Crowdin interface.

Implementation suggestion: whoever is going to work on it should do it in two pull requests: one to edit the user guide, the other on managing insufficiently translated localization data. The first one is a bit easier although the list of languages to be listed in the user guide should be reviewed to make sure the listed languages are localized to some extent (and I don't think we can guarantee that until 2026.1 betas are released and translatable string freeze is in effect). I think a survey of translators (subscribed to the translations mailing list) should be done to gather the current state of localization and their workflows.

Thanks.

[nidza07]

Hi,
I would seriously consider dropping the list of languages from the user guide completely.

Since the switch to Crowdin, we no longer have fuzzy messages. This means that each time a single language is added to this list, we have to re-translate the entire list again, which is very exhausting, or manually try to compare the old list and the new list, which requires first saving/accessing the old user guide. Of course, this issue isn't limited to the list of supported languages, for instance we have to re-add translations for screen curtain as well even though in the past, this would just require minor changes as the existing translations were kept as fuzzy messages, but the list of languages is something that is updated relatively often. If I had to choose, this would be the biggest annoyance for me with the switch to Crowdin, I can't stress how much more work and overhead this adds, with a single comma or period removed somewhere, or a single shortcut changed, the entire translation is lost and has to be added again.

Alternatively, for the list of languages, you could consider having each language as its own separate list item instead of one sentence with all languages, that way they will at least be separate strings and when a new one is added, it will be easier to translate just that new one. I still seriously hope that the issue with fuzzy messages can somehow be resolved though, but I understand that's not the original topic of this issue.

[wmhn1872265132]

To use fuzzy messages, there are two options for reference:

• Using the Crowdin web interface, found below the edit box for entering translations
• If you want to translate locally:
  • Extract your language's previous version of nvda.po from the NVDA source code, or keep your last uploaded nvda.po file
  • Download nvda.pot from the beta version’s CI/CD page
  • Update nvda.po using that nvda.pot
  • Translate and upload new files.

[SaschaCowley]

We have chosen to convert this to a discussion, as it relies on our clarifying our policy for how translations are supported over time. For instance:

• What is the threshold for a translation to be accepted into NVDA?
• What are our expectations of its translators while it is in NVDA?
• When, if ever, should a translation be removed from NVDA?
• If not all, which of the translations should be listed in the user guide, on the website etc?

We will be working on a policy to clarify this and sharing it for community feedback in due course.

[CyrilleB79]

@SaschaCowley, I agree that the request in #19470 was a bit broad and may lead to discussion. Though in this issue, there was at least 2 real and actionable issues:

1. Bangla translation should be removed since it is completely empty, has always been, and since there is no volunteer anymore to work on it.
2. The number and the list of languages in the User Guide does not match the one in General Settings.

Could you or @seanbudd take care of 1.? I may modify the User Guide for 2. if needed.

[CyrilleB79]

@seanbudd, you write:

We want to keep the list of supported languages in the User Guide, but instead make it a list to make updating it easier. It might be possible to generate the language list when compiling the docs as well, which solves keeping it up-to-date.

Do you plan to do so for 2026.1?
If not, I'd suggest at least to remove temporarily the list for 2026.1 rather than keeping today's inaccurate one. We can just say that NVDA is translated in more than 60 languages.

Regarding generating the list when compiling the doc, can you be more specific? What do you have in mind?

More generally, I think that a bullet list is not suitable for a list of more than 60 items. Visually, it's really unappealing. For beginners who read documents line by line pressing downArrow and who do not yet know the "Moves past the end of the container element" command (comma), it's also very long!

At last regarding Bangla removal, I have opened a dedicated less broad issue (#19643 ).

[seanbudd]

We don't plan to do this, but welcome a PR turning the list into a proper list.
I disagree that today's list is significantly misleading or inaccurate. As mentioned previously, we find it valuable to explicitly list which languages are supported. It's worth keeping for now, even if our future policy results in removing some of the entries.

Regarding generating the list when compiling the doc, can you be more specific? What do you have in mind?

Using some form of macro to create the list in the markdown to HTML stage, so that the markdown files just have a marker like %languageList%

[CyrilleB79]

We don't plan to do this, but welcome a PR turning the list into a proper list.
I disagree that today's list is significantly misleading or inaccurate. As mentioned previously, we find it valuable to explicitly list which languages are supported. It's worth keeping for now, even if our future policy results in removing some of the entries.

Sorry, I may not have been very clear here. My point is not about languages with low coverage here.
It's about the inconsistancies between the list in the GUI settings and the list in the User Guide, i.e. missing items in the User Guide, inconsistancy with regional variants which are sometimes mentioned, and sometimes not, etc. See the 4 first points of the Steps to reproduce section in the initial description for more details.

Regarding generating the list when compiling the doc, can you be more specific? What do you have in mind?

Using some form of macro to create the list in the markdown to HTML stage, so that the markdown files just have a marker like %languageList%

And how would you feel the content that should replace %languageList%?

• Do you imagine a list of language names that would be generated from supported language codes? But in this case, it should be generated in all translations... How?
• Or do you just imagine a separate list of languages, somewhere, that translators would still have to translate?

Sorry, all this is not very clear to me.

[SaschaCowley]

Using some form of macro to create the list in the markdown to HTML stage, so that the markdown files just have a marker like %languageList%

And how would you feel the content that should replace %languageList%?

We know which locales are supported because we have the po files for those locales. We know the name of those locales in each supported locale, because translators have already translated them (alternatively we could use CLDR for this). When generating the user guide, we know which locale it is for. So the plan is to take the list of supported locales, filter it if necessary, and retrieve the localized name for each locale to build the list of supported languages.

[CyrilleB79]

@SaschaCowley wrote:

We know which locales are supported because we have the po files for those locales.

Correct and easy to list.

We know the name of those locales in each supported locale, because translators have already translated them

Not correct. Most of the language names used in "NVDA language" combobox of general settings panel are retrieved from Windows API; by the way they are expressed in the language of current Windows session, not in NVDA GUI language.

(alternatively we could use CLDR for this).

OK. I do not know the complexity for this. Maybe easy too with Babel package?

[CyrilleB79]

Hi @seanbudd

Now that Bangla has been removed from the interface, here is updated information regarding mismatch or imprecision between the User Guide and the actual languages list in the GUI:

1. The languages list contains 65 items. If you remove default user and English, 63 items are remaining. Though, the User Guide indicates that NVDA is translated into 56 languages. This is not consistent.
2. In the UG, we indicate that NVDA is translated to "Chinese (simplified and traditional)", but for traditional, there is no indication that both translations to Taïwan and Hong-Kong traditional Chinese exist in NVDA.
3. In the list of existing NVDA translation in the UG, we indicate "Norwegian", but do not specify that both Bokmål and Nynorsk versions exist. On the contrary, we indicate e.g. "German (Germany and Switzerland)".
4. The following languages appear in the language list in NVDA's general settings, but not in the list of translated languages in the User Guide: Indonesian (id), Central Kurdish (ckb), Northern Kurdish (kmr), Urdu (ur), Somali (so).

IMO this information is actual and actionable (surely points 1 and 4 at least). It would be better to track it in an issue, rather than keeping this information buried in a discussion. Would you accept it?
The issue would focus on UG vs GUI mismatch and UG consistency (variant listing).
The issue can then be blocked, (needs-product-decision) if needed, if you (NV Access), would like to discuss formatting or auto-generation of the list first.

All the discussion around low level coverage should not be part of this future issue and can remain here.

Thanks.

[seanbudd]

Hi Cyrille,

We're still working on a policy document on how we want to handle this