Add-on translation


Cyrille
 

Hi Ângelo

 

I will not reply to all the long thread dedicated to English usage in add-on development and communication in the community, even if there would be many things to write. Hence I have changed the subject.

 

You have expressed your disappointment regarding an answer you have received when sending your translations. But I would like to take this opportunity to try to improve things.

If I understand correctly, you have preferred to send your translation directly to the author (via e-mail or maybe direct pull-request) rather than to use the integrated translation framework using the screenreadertranslation (SRT) SVN repo.

Why doesn’t the SRT repo satisfy your needs?

Which add-on did you translate?

From my point of view, as a translator and as an add-on author, I feel that using the SRT is more smooth and efficient than sending or receiving and integrating manual translations. Maybe because I am already used to it. Anyway, if your opinion differs on this point, let me know why; this could be interesting.

Also note that the translation framework via the SRT repo has experienced many issues during one year and a half (beginning 2020 to mid-2021). From mid-2021 onwards, the problems seem to be solved quite quickly thanks to NVAccess (Reef Turner) provided you report it; let me know if you face any issue. These days of course, you may have to wait a little bit more due to summer holiday of NVAccess people in Australia.

 

I agree that many add-on are not translatable via the automatic system or even not manually translatable. It is the responsibility of the community to encourage add-on authors to ease their add-on translatability.

 

Cheers,

 

Cyrille

 

 

 

De : nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> De la part de Ângelo Abrantes
Envoyé : mercredi 5 janvier 2022 21:18
À : nvda-addons@nvda-addons.groups.io
Objet : Re: [nvda-addons] This message is so that all users can reflect on this unusual but real situation!

 

Unfortunately, according to many things that are going on this list, the English-speaking community has Primasia on all the remaining.
I already know that, as always happens, some individuals will appear to say that this is not true!
Just look at the numbers, which do not deceive: if you compare the number of addons who are on the official NVDA page with the number of those who have their messages available to be translated, you will reach your own conclusions!
What is the medium through which an addon can be operationalized by your user?
Please do not tell me that this is done through the presence of addon on the official NVDA page!
Messages from an addon are interaction vehicle with your user ...
Yesterday, I spent about eight hours translating, documentation and messages, from an addon. In the end, what a donkey I am, I sent these translations to the author of Addon. Do you know what the answer I received? Something like: translations are done through the official NVDA page!
Do you know what I did?
I proceeded to the distribution of addon by the Portuguese-speaking community, because, in reality, this is my community!
To finish this message, which is already long and will be translated by Google, not making any changes, I leave for you the following conclusion:
All the work I do for this screen reader is totally voluntary. With the support I have felt, I'm not too far from giving up all this!
Congratulations and wishes of a good New Year, for all.
Ângelo Abrantes, Portuguese team of NVDA.

Às 19:47 de 05-01-2022, Héctor Javier Benítez Corredera escreveu:

Hello and I think that as I was named in the initial mail I will finish with this last mail I send on the subject.

My plugins are translated into several languages both documentation and strings.

They are always tested first in the Spanish community and then I receive translations about the acceptance of the add-on.

Well I understand the philosophy of NVDA.

But as I have read that it is in English and has to be in English I will simply refer to a line of the buildVars.py exactly the last one:

baseLanguage = "es"

This line makes mention to indicate in which language the plugin is in natively.

Well if I wanted to contribute internal code for NVDA what I have very clear is that of course I would strive to try to communicate both what I want to contribute and the conversation that could happen in English.


But on the blue planet we live on there is not only the English speaking community in terms of plugins which is where this whole thread is coming from.
Well several reflections.

If I get an email asking me for something and it is not understood that we are on holidays or that for x reasons I do not want to accept a change in something that I have developed, the one who requests it should understand why the developer.

All my projects are on Github and I do not put any impediment to clone, fork and let everyone do what they want.

But if they demand me and then send me to the front with a thread like this, I will not pass.

Well in another forum of Audio Games the same thing has been requested that here and the problem is that I am not going to change a name of a class because somebody does not understand it:

Class dialogo(wx.Dialog):

Why they want it to be:

Class mainWindows(wx.Dialog):

Well making very clear that that complement that comes everything is translated to Turkish, English, French, Arabic and Spanish.

Therefore what the translator needs is perfectly accessible to be translated.

As I said I refuse to have to translate classes, functions or variables and in fact as I look for information many of them are in English already by habit.

Well my annoyance is that on top of the matter publicly it is said that it is necessary to reflect and that it is unusual.

Well, at least I have reflected and sincerely I stay with my family and as I have always said I program on needs that I have and then freely share in case someone could be worth.

Well weighing everything my reflection is that soon more of my plugins will be discontinued and will be for those who want to translate classes, variables and functions because I don't plan to take that time away from my family.

And about the unusual.

Well if it is unusual the tantrum of some people because things are not done as one wants and do not know how to accept that as a developer I can have some reason for example not to remove a part of code or not to touch something.

Well you can see it well in the add-on Packer add-on in the last pull that I had to reject and I explain why not.

Well from there I create this scorn for here and for another very famous forum that I named above.

Really one gives his work to the community of good will but if I am not going to compromise already painting gray hair is in demands and less I will endure tantrums as in the forum mentioned above or simply naming me in the first message and putting the subject to this thread.

More than one I believe that if it would have to reflect what it gets with their attitudes.

As I say I have reflected and will act accordingly.

And thanks must be given to whom it corresponds I do a lot by taking time off from my family, which is something that some people do not value or understand.

Eye and like me many developers here.

Happy new year and for my topic I apologize again to the moderation.

Best regards to all.

p.s.: Apologies if something is lost in the translator but in Spanish the mail looks nice.

El 05/01/2022 a las 18:18, Brian Vogel escribió:

On Wed, Jan 5, 2022 at 11:06 AM, ChrisLM wrote:

It would be a little controversial to use another language for additional components or contributions of code or documentation regarding an English-speaking project.

-
If you are intending whatever you're contributing to be "for official use," then I'd say that at a bare minimum:
1. It needs to be built to handle language localization.
2. It's initial state should include English as one localization, with the native language of the developer as a second, if this is at all possible.  If the English translation is not easily created at the time of release, it can be added later provided design for language localization is built-in.

But, a very, very great many add-ons have been born without the intention that they would ever see the light of day beyond the person who created it and, possibly, a few friends.  Then, after others learn of these by word of mouth, they take on a life of their own.  If someone wants to offer those for use in the "not officially vetted" and "use at your own risk" side of a centralized repository, nothing at all should be done to discourage that.  And the original developer need not be expected to do anything else, either.

If another developer were to find an "unvetted" add-on that they feel deserves reworking into a "for official use" add-on, then that's great, and that would require language localization capability to be built in as part of it.

Open source projects are just that.  And the beauty of this is it allows certain clever people who never have and never will envision themselves as software developers to "throw together something for myself" and then share that with others.  There should be no expectation that anything that someone might create will have, or should have, worldwide distribution as part of its design ethos.

How something is conceived of being used, and by whom, when it is created dictates how it is put together.  Not everything starts out life being conceived of as being "for everyone across the world."  But if someone wants to share it afterward, more power to them.  And if someone then wants to take the next step to make it an add-on that supports language localization, more power to them.
--
Brian - Windows 10, 64-Bit, Version 21H2, Build 19044

Any idiot can face a crisis. It's the day-to-day living that wears you out.

      ~ Anton Chekhov

-- 
Cordiais Cumprimentos
Ângelo Abrantes, Equipa <Portuguesa do NVDA

 


Avast logo

Este e-mail foi verificado em termos de vírus pelo software antivírus Avast.
www.avast.com




Rui Fontes
 

Hello!

Not answering in name of Ângelo, but as the other member of portuguese team...


Às 23:10 de 05/01/2022, Cyrille via groups.io escreveu:
If I understand correctly, you have preferred to send your translation directly to the author (via e-mail or maybe direct pull-request) rather than to use the integrated translation framework using the screenreadertranslation (SRT) SVN repo.

Why doesn’t the SRT repo satisfy your needs?


Because, in this specific case, the add-on is not yet in the translation system...



Which add-on did you translate?


BrowserNav.



From my point of view, as a translator and as an add-on author, I feel that using the SRT is more smooth and efficient than sending or receiving and integrating manual translations. Maybe because I am already used to it.


Yes, and maybe also because you work very well with GitHub and subversions...

Ângelo almost do not use GitHub and I, as a add-on author have great difficulties doing all operations to merge translations...



I agree that many add-on are not translatable via the automatic system or even not manually translatable. It is the responsibility of the community to encourage add-on authors to ease their add-on translatability.

Not only encourage, but not allowing add-ons not translatable to go to the offitial add-ons repository...


Rui Fontes



Cyrille
 

Hello Rui

To progress on browserNav translation, I have opened the following issue in the repo:
http://github.com/mltony/nvda-browser-nav/issues/3
Let's hope Tony will have time to address it.

Regarding translators and the difficulty to use the automatic translation system, fortunately translators do not have to use Git, and they have to use SVN in the most simple way that can be (e.g. no branch, labels, etc.). I admit however that Tortoise SVN is an additional tool that they need to learn and use. If this tool is causing problem, they may always ask for help on the translation mailing-list.
In any case, Ângelo, as a translator, only needs to know SVN, not Git.
In any case, if we want to reduce the workload of add-on authors regarding translations integration, a tool and/or at least a strict process is required (SVN or whatever else). Having an automatic system also proves to have more language translated: just compare the number of languages for add-ons in the automatic system with the number of languages of add-ons manually translated;

Regarding add-on authors and Git. I maintain that Git and the automatic translation system ease the add-on maintenance and the integration of translations with respect to manual integration.
I really encourage you, as an author already using Git, to use it for translation integration. If it's difficult, ask for help on the mailing list and I or other will try to help.

And regarding help request on the mailing lists:
Sometimes someone asks for help on a mailing list and get no answer. If this is your case, do not hesitate to ask again. The vast majority of people reading the mailing-list are volunteers and may not have so much time to answer to all requests. Personally, due to lack of time, I do not always answer to all the requests even if I know the answer. But if there is a second request asking for an answer, I am more inclined to answer.

At last, let's speak about untranslatable add-ons:
You advise to remove them from the official add-on repository.
At the end, with the add-on store, it will be NVAccess decision. In the meantime, I do not think that we should add new rules for add-on inclusion unless it takes the same direction as the add-on store project.
What is sure is that NVAccess want to have inclusion criteria that can be automatically checked. Regarding translation, you can check automatically that 'scons pot' command is working correctly, i.e. generating the .pot file. But you cannot evaluate the quality of its result, i.e. if all the UI strings are translatable (i.e. in the .pot) or only half of them.

Hope this helps.
Cheers,

Cyrille



 
De : "Rui Fontes"
A : nvda-addons@nvda-addons.groups.io
Envoyé: jeudi 6 Janvier 2022 13:50
Objet : Re: [nvda-addons] Add-on translation
 

Hello!

Not answering in name of Ângelo, but as the other member of portuguese team...

 

Às 23:10 de 05/01/2022, Cyrille via groups.io escreveu:
If I understand correctly, you have preferred to send your translation directly to the author (via e-mail or maybe direct pull-request) rather than to use the integrated translation framework using the screenreadertranslation (SRT) SVN repo.

Why doesn’t the SRT repo satisfy your needs?

 

Because, in this specific case, the add-on is not yet in the translation system...

 

 

Which add-on did you translate?

 

BrowserNav.

 

 

From my point of view, as a translator and as an add-on author, I feel that using the SRT is more smooth and efficient than sending or receiving and integrating manual translations. Maybe because I am already used to it.

 

Yes, and maybe also because you work very well with GitHub and subversions...

Ângelo almost do not use GitHub and I, as a add-on author have great difficulties doing all operations to merge translations...

 

 

I agree that many add-on are not translatable via the automatic system or even not manually translatable. It is the responsibility of the community to encourage add-on authors to ease their add-on translatability.

Not only encourage, but not allowing add-ons not translatable to go to the offitial add-ons repository...

 

Rui Fontes

 


Noelia Ruiz
 

Helo: I am an add-on author (not translator). Also, I help forking add-ons on the nvdaaddons organization since it"s needed to use the automated translations system. I don"t accept po files attached to my email since it requires lot of time for me. Control versions system are widely used and, if someone needs"help, can request it, as mentioned by Cyrille.If someone cannot use control version due to learning disabilities or other major causes, of course this will bebe an exception for me and I can understund it. But in general I don"t want to waste extra time including translations manually, with more risk of mistakes. About the website, time ago it was known that reviews of new versions of existing add-ons weren"t performed or almos not performed. Recently I found, accidentally, an add-on with a bad last tested NVDA version. What I mean is that reviews, with lots of add-ons and just a few volunteers to review in a systematic way, reviews are not possible in fact. In addition, maybe add-ons intended to be used in a particular application for specific languages. So I think it"s not possible to determine what add-ons should be excluded on the website. This is my opinion, agreeing with Cyrille.
Enviado desde mi iPhone

El 6 ene 2022, a las 15:58, Cyrille via groups.io <cyrille.bougot2@...> escribió:


Hello Rui

To progress on browserNav translation, I have opened the following issue in the repo:
http://github.com/mltony/nvda-browser-nav/issues/3
Let's hope Tony will have time to address it.

Regarding translators and the difficulty to use the automatic translation system, fortunately translators do not have to use Git, and they have to use SVN in the most simple way that can be (e.g. no branch, labels, etc.). I admit however that Tortoise SVN is an additional tool that they need to learn and use. If this tool is causing problem, they may always ask for help on the translation mailing-list.
In any case, Ângelo, as a translator, only needs to know SVN, not Git.
In any case, if we want to reduce the workload of add-on authors regarding translations integration, a tool and/or at least a strict process is required (SVN or whatever else). Having an automatic system also proves to have more language translated: just compare the number of languages for add-ons in the automatic system with the number of languages of add-ons manually translated;

Regarding add-on authors and Git. I maintain that Git and the automatic translation system ease the add-on maintenance and the integration of translations with respect to manual integration.
I really encourage you, as an author already using Git, to use it for translation integration. If it's difficult, ask for help on the mailing list and I or other will try to help.

And regarding help request on the mailing lists:
Sometimes someone asks for help on a mailing list and get no answer. If this is your case, do not hesitate to ask again. The vast majority of people reading the mailing-list are volunteers and may not have so much time to answer to all requests. Personally, due to lack of time, I do not always answer to all the requests even if I know the answer. But if there is a second request asking for an answer, I am more inclined to answer.

At last, let's speak about untranslatable add-ons:
You advise to remove them from the official add-on repository.
At the end, with the add-on store, it will be NVAccess decision. In the meantime, I do not think that we should add new rules for add-on inclusion unless it takes the same direction as the add-on store project.
What is sure is that NVAccess want to have inclusion criteria that can be automatically checked. Regarding translation, you can check automatically that 'scons pot' command is working correctly, i.e. generating the .pot file. But you cannot evaluate the quality of its result, i.e. if all the UI strings are translatable (i.e. in the .pot) or only half of them.

Hope this helps.
Cheers,

Cyrille



 
De : "Rui Fontes"
A : nvda-addons@nvda-addons.groups.io
Envoyé: jeudi 6 Janvier 2022 13:50
Objet : Re: [nvda-addons] Add-on translation
 

Hello!

Not answering in name of Ângelo, but as the other member of portuguese team...

 

Às 23:10 de 05/01/2022, Cyrille via groups.io escreveu:
If I understand correctly, you have preferred to send your translation directly to the author (via e-mail or maybe direct pull-request) rather than to use the integrated translation framework using the screenreadertranslation (SRT) SVN repo.

Why doesn’t the SRT repo satisfy your needs?

 

Because, in this specific case, the add-on is not yet in the translation system...

 

 

Which add-on did you translate?

 

BrowserNav.

 

 

From my point of view, as a translator and as an add-on author, I feel that using the SRT is more smooth and efficient than sending or receiving and integrating manual translations. Maybe because I am already used to it.

 

Yes, and maybe also because you work very well with GitHub and subversions...

Ângelo almost do not use GitHub and I, as a add-on author have great difficulties doing all operations to merge translations...

 

 

I agree that many add-on are not translatable via the automatic system or even not manually translatable. It is the responsibility of the community to encourage add-on authors to ease their add-on translatability.

Not only encourage, but not allowing add-ons not translatable to go to the offitial add-ons repository...

 

Rui Fontes