-
-
Notifications
You must be signed in to change notification settings - Fork 767
Validate translations before adding to NVDA #18269
Copy link
Copy link
Labels
component/i18nexisting localisations or internationalisationexisting localisations or internationalisationp3https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priorityhttps://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priorityrelease/blockingthis issue blocks the milestone releasethis issue blocks the milestone releasetriagedHas been triaged, issue is waiting for implementation.Has been triaged, issue is waiting for implementation.workflow/automated-translation
Milestone
Metadata
Metadata
Assignees
Labels
component/i18nexisting localisations or internationalisationexisting localisations or internationalisationp3https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priorityhttps://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priorityrelease/blockingthis issue blocks the milestone releasethis issue blocks the milestone releasetriagedHas been triaged, issue is waiting for implementation.Has been triaged, issue is waiting for implementation.workflow/automated-translation
Related issues, PRs or discussions
#18250
What is the current state of the codebase?
Before moving to Crowdin for translation management, we used a custom translation system. This system included functionality for checking for format string syntax errors in po files.
Why are changes required?
Now that we have moved to Crowdin and GitHub Actions for managing NVDA translations, these safeguards are no-longer in place. This means that typos in translations have the potential to stop parts of NVDA from working.
What technical changes are required?
Restore the po file checking back to the translation process. For instance, implement the old functionality in a custom pre-commit hook. This will need to consider how to notify translators that their language's translations contain errors.
Are the proposed technical changes API breaking?
No.
Are there potential risks or issues with the proposed implementation?
There is the risk that translations that would work will erroneously fail the syntax checks. However, this is unlikely.