Let's start by describing the benefits and drawbacks of using gettext to translate user guides, changelogs, and development documentation.
The benefits are.
1. easy to distribute.
After using sphinx+gettext to translate the above files, multiple file formats can be generated, such as: txt, chm, epub, html, and so on.
So users and developers can use multiple devices to learn and use NVDA.
2, Easy to manage.
The current txt2tag needs to be edited by an editor when translating. If NVDA updates the last number of documents, the translation maintainer needs to open wordDifferences.txt to copy the new entries to the maintained language file for translation, which affects the translation efficiency.
In addition, if a new NVDA translation maintainer has to learn txt2tag syntax in order to translate NVDA superscript files, I think this is a very inefficient way to work in 2021.
3, easy to integrate with github's code base
At present, NVDA translators need to use svn to exchange data with github's code, which makes it impossible to test their own translations from time to time. The way I usually test the modified translations is: first modify the new translation entries, then use poedit to generate the modified .po files into wi.mo files, and finally replace the .mo files into the translated language directory.
After using gettext, you can introduce crowdin and Weblate to synchronize and test the translations in time.
This can save a lot of translation work time and improve translation efficiency.
It is even possible to build a translation test build specifically to test the translations.
Finally, the translation maintainer can also use the webpage to update the upper number of translations.
As we all know, everything has its shortcomings, and using gettext to translate NVDA documents also has some unsatisfactory points.
Firstly, the flexibility is reduced.
Secondly, there are more repositories to manage