Topics

NVDA translation system was: RE: [nvda-addons] NVDA Core dev docs: you can now build it locally via Sphinx


zvonimir stanečić, 9a5dsz
 

Hi to all!

Let’s give my arguments on the matter

I am against using gettext for translating NVDA documentation, that is user guide and changes.

First of all, In the past I was able to choose which parts of the documentation I wanted to translate, that is: I was able to exclude changes for developers from this translation.

In my opinion, changes for developers firstly should be separated, if we want to to do such a thing.

I want to hear from Reef, Joseph, Michael and/or Quentin on this matter.

Best,

Zvonimir

 

From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of dingpengyu
Sent: Tuesday, January 12, 2021 6:48 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] NVDA Core dev docs: you can now build it locally via Sphinx

 

It would be nice if we could use gettext to make NVDA documents translatable.


 

I don't see any reason on compiling the documentation in the first place.

Why can't the documentation be on the website and such.

I guess for source and alphas/ snapshots/ betas I guess I could understand but for stable versions, or such who knows.

Either that or something that will compile the latest documentation and previde snapshots online of the latest documentation.

For betas and stable releases, documentation should be on the website or a one for that sort of thing.

At any rate once you have documentation which is the latest without any changes you should just be able to get it.



On 12/01/2021 7:07 pm, zvonimir stanečić, 9a5dsz wrote:

Hi to all!

Let’s give my arguments on the matter

I am against using gettext for translating NVDA documentation, that is user guide and changes.

First of all, In the past I was able to choose which parts of the documentation I wanted to translate, that is: I was able to exclude changes for developers from this translation.

In my opinion, changes for developers firstly should be separated, if we want to to do such a thing.

I want to hear from Reef, Joseph, Michael and/or Quentin on this matter.

Best,

Zvonimir

 

From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of dingpengyu
Sent: Tuesday, January 12, 2021 6:48 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] NVDA Core dev docs: you can now build it locally via Sphinx

 

It would be nice if we could use gettext to make NVDA documents translatable.


Brian's Mail list account
 

Ho ho, you should realise its never that simple with programmers in charge of the system cheesy grin.
Brian

bglists@blueyonder.co.uk
Sent via blueyonder.
Please address personal E-mail to:-
briang1@blueyonder.co.uk, putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

----- Original Message -----
From: "Shaun Everiss" <sm.everiss@gmail.com>
To: <nvda-addons@nvda-addons.groups.io>
Sent: Tuesday, January 12, 2021 6:57 AM
Subject: Re: NVDA translation system was: RE: [nvda-addons] NVDA Core dev docs: you can now build it locally via Sphinx


I don't see any reason on compiling the documentation in the first place.

Why can't the documentation be on the website and such.

I guess for source and alphas/ snapshots/ betas I guess I could
understand but for stable versions, or such who knows.

Either that or something that will compile the latest documentation and
previde snapshots online of the latest documentation.

For betas and stable releases, documentation should be on the website or
a one for that sort of thing.

At any rate once you have documentation which is the latest without any
changes you should just be able to get it.



On 12/01/2021 7:07 pm, zvonimir stanečić, 9a5dsz wrote:

Hi to all!

Let’s give my arguments on the matter

I am against using gettext for translating NVDA documentation, that is
user guide and changes.

First of all, In the past I was able to choose which parts of the
documentation I wanted to translate, that is: I was able to exclude
changes for developers from this translation.

In my opinion, changes for developers firstly should be separated, if
we want to to do such a thing.

I want to hear from Reef, Joseph, Michael and/or Quentin on this matter.

Best,

Zvonimir

*From:* nvda-addons@nvda-addons.groups.io
<nvda-addons@nvda-addons.groups.io> *On Behalf Of *dingpengyu
*Sent:* Tuesday, January 12, 2021 6:48 AM
*To:* nvda-addons@nvda-addons.groups.io
*Subject:* Re: [nvda-addons] NVDA Core dev docs: you can now build it
locally via Sphinx

It would be nice if we could use gettext to make NVDA documents
translatable.





 

hello all
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.
4. Deficiencies
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
thanks


zvonimir stanečić, 9a5dsz
 

And thirdly, i cannot choose what I don’t want to translate.

I don’t want to translate developer documentation in the changelog for all my languages I maintain.

By using po files, I will had a less flexibility.

 

 

From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of dingpengyu
Sent: Wednesday, January 13, 2021 3:29 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: NVDA translation system was: RE: [nvda-addons] NVDA Core dev docs: you can now build it locally via Sphinx

 

hello all

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.

4. Deficiencies

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

thanks