Skip to content
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

Add-on store - Add-on information is in English #14973

Closed
CyrilleB79 opened this issue Jun 6, 2023 · 16 comments · Fixed by #15152
Closed

Add-on store - Add-on information is in English #14973

CyrilleB79 opened this issue Jun 6, 2023 · 16 comments · Fixed by #15152
Labels
component/i18n existing localisations or internationalisation feature/addon-store Features / behavior of the add-on Store feature/i18n Internationalization features p3 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority triaged Has been triaged, issue is waiting for implementation.
Milestone

Comments

@CyrilleB79
Copy link
Collaborator

Steps to reproduce:

  • Open add-on store in available add-on and installed add-on tabs

Actual behavior:

The add-on name and the add-on description are in English no matter NVDA's language.

Expected behavior:

The add-on name and description should honor NVDA's language if a translation exists in the add-on.

NVDA logs, crash dumps and other attachments:

N/A

System configuration

NVDA installed/portable/running from source:

Portable

NVDA version:

nvda_snapshot_alpha-28355,02199b76

Windows version:

Windows 10 21H2 (AMD64) build 19044.2965

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?

Not tested

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?

Not tested, unrelated

Additional note

  • Regarding the installed add-on tab, it's a regression with respect to old add-on manager which displayed translated information for installed add-ons (and for incompatible add-ons).
  • Regarding the available add-on, browsing the community website where the information is translated may be preferred by non-English speaking users.
  • IMO translation should be priorized and even included in 2023.2 if we want the add-on store to be accepted and adopted by non-English speaking users (who are the majority of the users). I fear however that providing translation for the available add-ons tab may be an important piece of work requiring an evolution in the add-on store database.
@seanbudd seanbudd added this to the 2023.2 milestone Jun 7, 2023
@seanbudd
Copy link
Member

seanbudd commented Jun 7, 2023

Hi @CyrilleB79, thanks for making an issue for this.
We aim to have translations supported both in NVDA and the addon-datastore server side ecosystem by 2023.2.

@seanbudd seanbudd added feature/addon-store Features / behavior of the add-on Store p3 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority triaged Has been triaged, issue is waiting for implementation. component/i18n existing localisations or internationalisation feature/i18n Internationalization features labels Jun 7, 2023
@ruifontes
Copy link
Contributor

Testing with NVDA Alpha-28584,5c4e6e1f all add-ons installed from the store have the name and description in english, since the information is based on .JSON file...
Add-ons installed from external sources have the name and description in NVDA language, in my case portuguese.
So, it seems that is enough to installed add-ons get the information from same place of external add-ons to solve the problem of no translation in the installed add-ons list...

seanbudd added a commit that referenced this issue Jul 14, 2023
Part of #14973

Summary of the issue:
Installed add-ons do not have their display name and description localised, even if localised manifests exist for the installed add-on.

Description of user facing changes
Reinstate localisation for installed add-ons of the display name and description

Description of development approach
Fetch translated strings from the localised manifests

Testing strategy:
Ensure add-on with localisations is correctly displayed in the installed add-ons tab of the store.
Available and updatable add-ons rely on the strings to be translated when fetching from the store.
@seanbudd
Copy link
Member

Alpha should now be using translated add-on store data correctly in the available and updatable add-on tab views

@nvdaes
Copy link
Collaborator

nvdaes commented Jul 17, 2023

Alpha should now be using translated add-on store data correctly in the available and updatable add-on tab views

Not in alpha-28690,08de8de3

Maybe next Alpha...

@nvdaes
Copy link
Collaborator

nvdaes commented Jul 17, 2023

Edition of my previous comment: This works in alpha if language is not set to default. If I set the language to Spanish it works well.

seanbudd added a commit that referenced this issue Jul 17, 2023
#15152)

Closes #14973

Summary of the issue:
Add-ons installed from the add-on store used the untranslated add-on store JSON strings.
As of #15137, only add-ons that were installed from an external source had translated strings.

Description of user facing changes
Add-ons installed from the add-on store will have translated strings.

Description of development approach
Create a separate model for add-ons fetched from the add-on store, and add-ons cached after being installed from the add-on store.
Data fetched from the add-on store should be translated. Installed cached data for an add-on will be whatever language is used when the fetched add-on store data is cached. As such, we should defer to the translated manifests for installed add-ons.
@seanbudd
Copy link
Member

@nvdaes - I am surprised if NVDA language is set to default, that this does not work. When using default language, and a Spanish system, can you confirm the value of cachedLanguage in _cachedCompatibleAddons.json ?

@nvdaes
Copy link
Collaborator

nvdaes commented Jul 17, 2023 via email

@CyrilleB79
Copy link
Collaborator Author

Same here: not working with system language = "fr_FR" vs working with forced language = "fr".

@seanbudd could you please reopen?

Also when fixing this, it may be interesting to test with:

  • "fr" (NVDA language) vs "fr_FR" (system language), or the same with "es" vs "es_ES"
  • NVDA language = "es_CO", i.e. NVDA language with a country code, opposed to only "es"
  • "pt_BR" or "pt_PT": NVDA language with country code for which no NVDA language with no country code exists (i.e. no "pt" version of NVDA exists)

@ruifontes
Copy link
Contributor

Tried using only "pt" as NVDA language and add-on information is not translated.
Other annoyance is the punctuation announced in english!

@CyrilleB79
Copy link
Collaborator Author

Tried using only "pt" as NVDA language and add-on information is not translated.

@ruifontes how can you use only "pt" as NVDA language? NVDA only has "pt_BR" and "pt_PT", not "pt" without country name. Please be more specific because, as explained before, the case of Portuguese is a corner case in NVDA and specific issues may occur only with this language.

Other annoyance is the punctuation announced in english!

Is this linked to this issue, i.e. the add-on store content being in English? If not, please open a separate issue.
Looking at 2023.2 milestone, beta stage seems very near, so please report it quickly so that it can be captured and fixed before beta release if possible.

@CyrilleB79
Copy link
Collaborator Author

Reopening, since I realize I can do it myself.

@CyrilleB79 CyrilleB79 reopened this Jul 17, 2023
@josephsl
Copy link
Collaborator

josephsl commented Jul 17, 2023 via email

@seanbudd
Copy link
Member

@josephsl - that's correct
The add-ons found in this GH search have translations for "pt". I'm not sure if NVDA will ever use these translations, unless perhaps the default Windows language is set to "pt" without a country code. pt is handled as pt_PT by gettext in NVDA.

@seanbudd
Copy link
Member

The add-on store server should now fallback to language without locale, if the language with locale is unsupported

@CyrilleB79
Copy link
Collaborator Author

The add-on store server should now fallback to language without locale, if the language with locale is unsupported

There is still an issue with "pt_PT" not listing the add-ons having only "pt". I have opàened #15173 for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component/i18n existing localisations or internationalisation feature/addon-store Features / behavior of the add-on Store feature/i18n Internationalization features p3 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority triaged Has been triaged, issue is waiting for implementation.
Projects
None yet
5 participants