Topics

Percentage Checker #addonrequestreview

Lukasz Golonka
 

Hi all,

A few years ago Oriol Gómez released an add-on called percentage
checker. It basically allows to check your position in a text field or
on a list. As it was not compatible with Python 3 I've decided - with
Oriol's permissions of course, to update it and maintain for the time
being.

As it is very useful I would like to have it published on the add-ons
website, hence my request for review.

The repository is available at:
https://github.com/lukaszgo1/percentageChecker/
The latest release can be found at:
https://github.com/lukaszgo1/percentageChecker/releases/download/V1.3/percentageChecker-1.3.nvda-addon

A few remarks:

I am aware that its name deviates from the usual naming scheme (there is
a space in the middle). The problem with renaming it to something more
conventional lies with the fact that I really would like for it to be
recognized by add-on updater as a new version for people who have
installed current add-on from Oriol.

The versioning is the similar story - starting from 1.0 would not make
add-on updater to register it as an update.


When review passes and it would be published on add-ons website I also
would like to have it included in the translations system.


--
Regards
Łukasz

 

Hi,
Basic review results:

* License and copyright: pass
* Documentation: pass
* Security: pass
* User experience: pass (with comments)
* Python 3 ready: yes
* Manifest: pass

Comments:

* Another approach for naming the add-on in the manifest might be using an underscore, similar to what was done for Weather Plus unless the original ad-on was named "percentage checker", in which case it should be called that for purposes of add-on updating (after all, Add-on Updater looks at manifest["name"] key).
* When percentage beeps are heard, they are not the progress bar pitches that are familiar to users. For some people, very low and very high percentage tones may pose hearing and/or health issues.
* Suggestion (in 2020): would it be possible to use an edit spin box for entering percentages or line numbers? Not only this will allow people to write percentages in text, users can also use up or down arrow keys to move up and down the percentage value and removes error checks for invalid entries (if an invalid entry is given, wxWidgets will use maximum value).

For now this add-on will go live under development section in the New Year; I'll wait until you say it is stable before making it available on the front page and via Add-on Updater (and add it to compatibility list, as this add-on is NVDA 2019.3 ready). Comments from others are appreciated.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Lukasz Golonka
Sent: Tuesday, December 24, 2019 11:47 AM
To: nvda-addons@nvda-addons.groups.io
Subject: [nvda-addons] Percentage Checker #AddonRequestReview

Hi all,

A few years ago Oriol Gómez released an add-on called percentage checker. It basically allows to check your position in a text field or on a list. As it was not compatible with Python 3 I've decided - with Oriol's permissions of course, to update it and maintain for the time being.

As it is very useful I would like to have it published on the add-ons website, hence my request for review.

The repository is available at:
https://github.com/lukaszgo1/percentageChecker/
The latest release can be found at:
https://github.com/lukaszgo1/percentageChecker/releases/download/V1.3/percentageChecker-1.3.nvda-addon

A few remarks:

I am aware that its name deviates from the usual naming scheme (there is a space in the middle). The problem with renaming it to something more conventional lies with the fact that I really would like for it to be recognized by add-on updater as a new version for people who have installed current add-on from Oriol.

The versioning is the similar story - starting from 1.0 would not make add-on updater to register it as an update.


When review passes and it would be published on add-ons website I also would like to have it included in the translations system.


--
Regards
Łukasz

Lukasz Golonka
 

Hello,

On Tue, 24 Dec 2019 12:12:56 -0800
"Joseph Lee" <@joslee> wrote:

* Another approach for naming the add-on in the manifest might be using an underscore, similar to what was done for Weather Plus unless the original ad-on was named "percentage checker", in which case it should be called that for purposes of add-on updating (after all, Add-on Updater looks at manifest["name"] key).

It was called "percentage checker" so we cannot use an underscore.


* When percentage beeps are heard, they are not the progress bar pitches that are familiar to users. For some people, very low and very high percentage tones may pose hearing and/or health issues.
I haven't thought of that - this part of the code was written by Oriol,
and I ported it as is, because this functionality is not useful to me
personally. You suggestion makes sense, so I'll implement it.

* Suggestion (in 2020): would it be possible to use an edit spin box for entering percentages or line numbers? Not only this will allow people to write percentages in text, users can also use up or down arrow keys to move up and down the percentage value and removes error checks for invalid entries (if an invalid entry is given, wxWidgets will use maximum value).
This also makes sense. I'll study a wx documentation and try to come up
with something in 2020, but TBH it is not a top priority for me.

For now this add-on will go live under development section in the New Year; I'll wait until you say it is stable before making it available on the front page and via Add-on Updater (and add it to compatibility list,
I believe it is stable already - it was available for a 5 years now, and
there were no complains, so the only way to gain more users would be to
mark it as stable.

Regarding adding it to the translation system could we done it when it
is still a development version?


--
Regards
Łukasz

 

Hi,
Adding Percentage Checker to translations: usually I'd wait for the add-on to show up on stable add-ons section - speaking of which, if you say yes, I'll do just that on New Year's Day, given it was out there for five years.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Lukasz Golonka
Sent: Tuesday, December 24, 2019 1:23 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Percentage Checker #AddonRequestReview

Hello,

On Tue, 24 Dec 2019 12:12:56 -0800
"Joseph Lee" <@joslee> wrote:

* Another approach for naming the add-on in the manifest might be using an underscore, similar to what was done for Weather Plus unless the original ad-on was named "percentage checker", in which case it should be called that for purposes of add-on updating (after all, Add-on Updater looks at manifest["name"] key).

It was called "percentage checker" so we cannot use an underscore.


* When percentage beeps are heard, they are not the progress bar pitches that are familiar to users. For some people, very low and very high percentage tones may pose hearing and/or health issues.
I haven't thought of that - this part of the code was written by Oriol, and I ported it as is, because this functionality is not useful to me personally. You suggestion makes sense, so I'll implement it.

* Suggestion (in 2020): would it be possible to use an edit spin box for entering percentages or line numbers? Not only this will allow people to write percentages in text, users can also use up or down arrow keys to move up and down the percentage value and removes error checks for invalid entries (if an invalid entry is given, wxWidgets will use maximum value).
This also makes sense. I'll study a wx documentation and try to come up with something in 2020, but TBH it is not a top priority for me.

For now this add-on will go live under development section in the New
Year; I'll wait until you say it is stable before making it available
on the front page and via Add-on Updater (and add it to compatibility
list,
I believe it is stable already - it was available for a 5 years now, and there were no complains, so the only way to gain more users would be to mark it as stable.

Regarding adding it to the translation system could we done it when it is still a development version?


--
Regards
Łukasz

 

Hi all,

Few release notes:

  • If Lucas agrees, stable version will be registered on January 1, 2020.

  • The add-on files key for this add-on will be "perChk".

Cheers,

Joseph

Lukasz Golonka
 

On Tue, 24 Dec 2019 13:27:05 -0800
"Joseph Lee" <@joslee> wrote:

Adding Percentage Checker to translations: usually I'd wait for the add-on to show up on stable add-ons section - speaking of which, if you say yes, I'll do just that on New Year's Day, given it was out there for five years.
I have to admit that I am quite new to the add-ons review/translations
process but in my opinion this approach is not that great. To explain
why I think it can be improved lets analyse two sample workflows.

Workflow 1 which I think is the currently used (please let me know if I
misunderstood something):

1. Developer requests a review of his/her add-on.
2. Assuming that review passes the add-on is either registered as a
development version, or promoted directly to the stable section.
3. after being declared stable and released with a given version number
(lets say 1.0) it is being added to the translations system.
4. When some time passes and there are enough translations to signify a
next release the translations are ,merged to the add-on repo and the
new version is released for this example it is 1.1.
The problems with this approach assuming that the 1.1 version contains
only new translations that is there were no identified issues between
1.0and 1.1:

The version number is increased without a good reason.
Developer has to create a new release just to update translations -
something which could easily be avoided with my second workflow, see
below.
For some users lack of the translation to their native language may be a
show stopper which in theory may cause some issues not to be identified
due to smaller user base.



Workflow 2:


1. Developer requests review of his/her add-on.
2. When review passes the add-on is added to the development section and
(if developer wishes so) to the translation system.
3. After some translations are created developer declares an add-on as
stable, it is moved to the stable section and released as a 1.0 with all
translations created until the release day.
The advantages are not only lac of problems with the first workflow, but
also bigger user base - I assume translators are testing their
translations and in turn the addon that is being translated.


Commends are appreciated.

--
Regards
Łukasz

Noelia Ruiz
 

Hi, imo this second workflow has advantages. Anyway, if the add-on has small stability and some messages have to be removed, this can be extra work for translators. So I think that at least the add-on has to have some stability. Of course messages can be removed also when the add-on has been declared stable, but maybe less probable.Comments are appreciated to, in case we chave to modify the documentation about translated add-ons.

Enviado desde mi iPhone

El 25 dic 2019, a las 13:29, Lukasz Golonka <lukasz.golonka@...> escribió:

On Tue, 24 Dec 2019 13:27:05 -0800
"Joseph Lee" <@joslee> wrote:

Adding Percentage Checker to translations: usually I'd wait for the add-on to show up on stable add-ons section - speaking of which, if you say yes, I'll do just that on New Year's Day, given it was out there for five years.
I have to admit that I am quite new to the add-ons review/translations
process but in my opinion this approach is not that great. To explain
why I think it can be improved lets analyse two sample workflows.

Workflow 1 which I think is the currently used (please let me know if I
misunderstood something):

1. Developer requests a review of his/her add-on.
2. Assuming that review passes the add-on is either registered as a
development version, or promoted directly to the stable section.
3. after being declared stable and released with a given version number
(lets say 1.0) it is being added to the translations system.
4. When some time passes and there are enough translations to signify a
next release the translations are ,merged to the add-on repo and the
new version is released for this example it is 1.1.
The problems with this approach assuming that the 1.1 version contains
only new translations that is there were no identified issues between
1.0and 1.1:

The version number is increased without a good reason.
Developer has to create a new release just to update translations -
something which could easily be avoided with my second workflow, see
below.
For some users lack of the translation to their native language may be a
show stopper which in theory may cause some issues not to be identified
due to smaller user base.



Workflow 2:


1. Developer requests review of his/her add-on.
2. When review passes the add-on is added to the development section and
(if developer wishes so) to the translation system.
3. After some translations are created developer declares an add-on as
stable, it is moved to the stable section and released as a 1.0 with all
translations created until the release day.
The advantages are not only lac of problems with the first workflow, but
also bigger user base - I assume translators are testing their
translations and in turn the addon that is being translated.


Commends are appreciated.

--
Regards
Łukasz


 

Hi,
Personally, I tend to use the first workflow, although there are times when I do resort to waiting until things are stable before releasing a new version.

To place our discussion in context, here's what happens when we get translation requests:
1. A copy of your add-on repo is created on Bitbucket for the purpose of keeping an eye on translations. I and Noelia recently talked to the original brains behind translations workflow (Mesar Hameed) about unifying our workflow under GitHub.
2. A special repo named "mrconfig" is used to transport translations. First, the new add-on is registered, then a schedule is created to exchange translations between translators and Bitbucket repo.
3. The Friday after the add-on is registered for translations, translators are notified about a new add-on via a new entry in their language translation settings file (lang/settings JSON database). A language team (one or more translators) wishing to translate an add-on would say "yes" by setting the new add-on value to "1" and commit it via Subversion.
4. Every Friday after that (Thursday for some), messages from the new add-on are sent to translators, and translators would work on it and submit it. This will work for languages where translators said "yes" to translating the new add-on (not all language teams respond with 1).
5. In return, translations commit bot would gather translations for the add-on and commit it to the newly created Bitbucket repo under "stable" branch. This happens at the same time as new or changed messages being sent to translators (every Friday).
6. Add-on authors would then pull in latest translations from Bitbucket. You must create a remote pointing to Bitbucket repo, and pull in stable branch commits from there to yours (either master or stable branch).
7. When authors are ready, the new add-on is released.
8. When releasing a new version from stable branch, a copy of this work must be committed to Bitbucket repo's stable branch so translations workflow can pick up things here and there.

My issue with the proposed workflow is step 7, especially if we think about translations: different authors have varying definition as to what is stable, and for some, how many language translations are sufficient to make it into stable release (currently 20 to 30 language teams send add-on translations on a regular basis). This is one of the reasons why I advise authors to not worry about translations until an add-on is declared stable; another reason is "last minute pulling out" - that is, an add-on goes through translations with no stable release, and for some reason, the add-on gets pulled from community add-ons website (most recent case is Word add-on).

When it comes to maintenance steps, I usually follow a combination of "release early, release often" and "do not put everything in 1.0". The first is employed in add-on snapshots, and second is used when releasing a stable release, knowing that I can get feedback from people along the way. As for translations, I try my best to devote a release once every quarter (three months) or semester (six months) to localizations; for add-ons such as Windows 10 App Essentials which are governed by continuous delivery model, every release (monthly or so) includes localization updates, although I try my best to devote maintenance releases to localization updates on a regular basis.

I do see merit in letting translations be a part of version 1.0.

Hope this clarifies things.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Lukasz Golonka
Sent: Wednesday, December 25, 2019 4:29 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Percentage Checker #AddonRequestReview

On Tue, 24 Dec 2019 13:27:05 -0800
"Joseph Lee" <@joslee> wrote:

Adding Percentage Checker to translations: usually I'd wait for the add-on to show up on stable add-ons section - speaking of which, if you say yes, I'll do just that on New Year's Day, given it was out there for five years.
I have to admit that I am quite new to the add-ons review/translations process but in my opinion this approach is not that great. To explain why I think it can be improved lets analyse two sample workflows.

Workflow 1 which I think is the currently used (please let me know if I misunderstood something):

1. Developer requests a review of his/her add-on.
2. Assuming that review passes the add-on is either registered as a development version, or promoted directly to the stable section.
3. after being declared stable and released with a given version number (lets say 1.0) it is being added to the translations system.
4. When some time passes and there are enough translations to signify a next release the translations are ,merged to the add-on repo and the new version is released for this example it is 1.1.
The problems with this approach assuming that the 1.1 version contains only new translations that is there were no identified issues between 1.0and 1.1:

The version number is increased without a good reason.
Developer has to create a new release just to update translations - something which could easily be avoided with my second workflow, see below.
For some users lack of the translation to their native language may be a show stopper which in theory may cause some issues not to be identified due to smaller user base.



Workflow 2:


1. Developer requests review of his/her add-on.
2. When review passes the add-on is added to the development section and (if developer wishes so) to the translation system.
3. After some translations are created developer declares an add-on as stable, it is moved to the stable section and released as a 1.0 with all translations created until the release day.
The advantages are not only lac of problems with the first workflow, but also bigger user base - I assume translators are testing their translations and in turn the addon that is being translated.


Commends are appreciated.

--
Regards
Łukasz

Lukasz Golonka
 

Hello,

Looking at it from a perspective of an NVDA user who does not speak
English can we really call the version without translations stable?
Unless there are any problems with my proposal I would like to proceed
as follows in the percentage checker case:

1. Register it as a dev version when convenient.
2. At the same time register it in the translations system.
3. I'll wait lets say until the end of January and then would release
version 1.3 as stable. I assume a month is ling enough for at least some
translations to show up.


--
Regards
Łukasz

On Wed, 25 Dec 2019 10:06:28 -0800
"Joseph Lee" <@joslee> wrote:

Hi,
Personally, I tend to use the first workflow, although there are times when I do resort to waiting until things are stable before releasing a new version.

To place our discussion in context, here's what happens when we get translation requests:
1. A copy of your add-on repo is created on Bitbucket for the purpose of keeping an eye on translations. I and Noelia recently talked to the original brains behind translations workflow (Mesar Hameed) about unifying our workflow under GitHub.
2. A special repo named "mrconfig" is used to transport translations. First, the new add-on is registered, then a schedule is created to exchange translations between translators and Bitbucket repo.
3. The Friday after the add-on is registered for translations, translators are notified about a new add-on via a new entry in their language translation settings file (lang/settings JSON database). A language team (one or more translators) wishing to translate an add-on would say "yes" by setting the new add-on value to "1" and commit it via Subversion.
4. Every Friday after that (Thursday for some), messages from the new add-on are sent to translators, and translators would work on it and submit it. This will work for languages where translators said "yes" to translating the new add-on (not all language teams respond with 1).
5. In return, translations commit bot would gather translations for the add-on and commit it to the newly created Bitbucket repo under "stable" branch. This happens at the same time as new or changed messages being sent to translators (every Friday).
6. Add-on authors would then pull in latest translations from Bitbucket. You must create a remote pointing to Bitbucket repo, and pull in stable branch commits from there to yours (either master or stable branch).
7. When authors are ready, the new add-on is released.
8. When releasing a new version from stable branch, a copy of this work must be committed to Bitbucket repo's stable branch so translations workflow can pick up things here and there.

My issue with the proposed workflow is step 7, especially if we think about translations: different authors have varying definition as to what is stable, and for some, how many language translations are sufficient to make it into stable release (currently 20 to 30 language teams send add-on translations on a regular basis). This is one of the reasons why I advise authors to not worry about translations until an add-on is declared stable; another reason is "last minute pulling out" - that is, an add-on goes through translations with no stable release, and for some reason, the add-on gets pulled from community add-ons website (most recent case is Word add-on).

When it comes to maintenance steps, I usually follow a combination of "release early, release often" and "do not put everything in 1.0". The first is employed in add-on snapshots, and second is used when releasing a stable release, knowing that I can get feedback from people along the way. As for translations, I try my best to devote a release once every quarter (three months) or semester (six months) to localizations; for add-ons such as Windows 10 App Essentials which are governed by continuous delivery model, every release (monthly or so) includes localization updates, although I try my best to devote maintenance releases to localization updates on a regular basis.

I do see merit in letting translations be a part of version 1.0.

Hope this clarifies things.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Lukasz Golonka
Sent: Wednesday, December 25, 2019 4:29 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Percentage Checker #AddonRequestReview

On Tue, 24 Dec 2019 13:27:05 -0800
"Joseph Lee" <@joslee> wrote:

Adding Percentage Checker to translations: usually I'd wait for the add-on to show up on stable add-ons section - speaking of which, if you say yes, I'll do just that on New Year's Day, given it was out there for five years.
I have to admit that I am quite new to the add-ons review/translations process but in my opinion this approach is not that great. To explain why I think it can be improved lets analyse two sample workflows.

Workflow 1 which I think is the currently used (please let me know if I misunderstood something):

1. Developer requests a review of his/her add-on.
2. Assuming that review passes the add-on is either registered as a development version, or promoted directly to the stable section.
3. after being declared stable and released with a given version number (lets say 1.0) it is being added to the translations system.
4. When some time passes and there are enough translations to signify a next release the translations are ,merged to the add-on repo and the new version is released for this example it is 1.1.
The problems with this approach assuming that the 1.1 version contains only new translations that is there were no identified issues between 1.0and 1.1:

The version number is increased without a good reason.
Developer has to create a new release just to update translations - something which could easily be avoided with my second workflow, see below.
For some users lack of the translation to their native language may be a show stopper which in theory may cause some issues not to be identified due to smaller user base.



Workflow 2:


1. Developer requests review of his/her add-on.
2. When review passes the add-on is added to the development section and (if developer wishes so) to the translation system.
3. After some translations are created developer declares an add-on as stable, it is moved to the stable section and released as a 1.0 with all translations created until the release day.
The advantages are not only lac of problems with the first workflow, but also bigger user base - I assume translators are testing their translations and in turn the addon that is being translated.


Commends are appreciated.

--
Regards
Łukasz




 

Hi,
Ah, a pilot program, I see. If you wish to take that route, go ahead.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Lukasz Golonka
Sent: Thursday, December 26, 2019 7:40 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Percentage Checker #AddonRequestReview

Hello,

Looking at it from a perspective of an NVDA user who does not speak English can we really call the version without translations stable?
Unless there are any problems with my proposal I would like to proceed as follows in the percentage checker case:

1. Register it as a dev version when convenient.
2. At the same time register it in the translations system.
3. I'll wait lets say until the end of January and then would release version 1.3 as stable. I assume a month is ling enough for at least some translations to show up.


--
Regards
Łukasz

On Wed, 25 Dec 2019 10:06:28 -0800
"Joseph Lee" <@joslee> wrote:

Hi,
Personally, I tend to use the first workflow, although there are times when I do resort to waiting until things are stable before releasing a new version.

To place our discussion in context, here's what happens when we get translation requests:
1. A copy of your add-on repo is created on Bitbucket for the purpose of keeping an eye on translations. I and Noelia recently talked to the original brains behind translations workflow (Mesar Hameed) about unifying our workflow under GitHub.
2. A special repo named "mrconfig" is used to transport translations. First, the new add-on is registered, then a schedule is created to exchange translations between translators and Bitbucket repo.
3. The Friday after the add-on is registered for translations, translators are notified about a new add-on via a new entry in their language translation settings file (lang/settings JSON database). A language team (one or more translators) wishing to translate an add-on would say "yes" by setting the new add-on value to "1" and commit it via Subversion.
4. Every Friday after that (Thursday for some), messages from the new add-on are sent to translators, and translators would work on it and submit it. This will work for languages where translators said "yes" to translating the new add-on (not all language teams respond with 1).
5. In return, translations commit bot would gather translations for the add-on and commit it to the newly created Bitbucket repo under "stable" branch. This happens at the same time as new or changed messages being sent to translators (every Friday).
6. Add-on authors would then pull in latest translations from Bitbucket. You must create a remote pointing to Bitbucket repo, and pull in stable branch commits from there to yours (either master or stable branch).
7. When authors are ready, the new add-on is released.
8. When releasing a new version from stable branch, a copy of this work must be committed to Bitbucket repo's stable branch so translations workflow can pick up things here and there.

My issue with the proposed workflow is step 7, especially if we think about translations: different authors have varying definition as to what is stable, and for some, how many language translations are sufficient to make it into stable release (currently 20 to 30 language teams send add-on translations on a regular basis). This is one of the reasons why I advise authors to not worry about translations until an add-on is declared stable; another reason is "last minute pulling out" - that is, an add-on goes through translations with no stable release, and for some reason, the add-on gets pulled from community add-ons website (most recent case is Word add-on).

When it comes to maintenance steps, I usually follow a combination of "release early, release often" and "do not put everything in 1.0". The first is employed in add-on snapshots, and second is used when releasing a stable release, knowing that I can get feedback from people along the way. As for translations, I try my best to devote a release once every quarter (three months) or semester (six months) to localizations; for add-ons such as Windows 10 App Essentials which are governed by continuous delivery model, every release (monthly or so) includes localization updates, although I try my best to devote maintenance releases to localization updates on a regular basis.

I do see merit in letting translations be a part of version 1.0.

Hope this clarifies things.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io
<nvda-addons@nvda-addons.groups.io> On Behalf Of Lukasz Golonka
Sent: Wednesday, December 25, 2019 4:29 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Percentage Checker #AddonRequestReview

On Tue, 24 Dec 2019 13:27:05 -0800
"Joseph Lee" <@joslee> wrote:

Adding Percentage Checker to translations: usually I'd wait for the add-on to show up on stable add-ons section - speaking of which, if you say yes, I'll do just that on New Year's Day, given it was out there for five years.
I have to admit that I am quite new to the add-ons review/translations process but in my opinion this approach is not that great. To explain why I think it can be improved lets analyse two sample workflows.

Workflow 1 which I think is the currently used (please let me know if I misunderstood something):

1. Developer requests a review of his/her add-on.
2. Assuming that review passes the add-on is either registered as a development version, or promoted directly to the stable section.
3. after being declared stable and released with a given version number (lets say 1.0) it is being added to the translations system.
4. When some time passes and there are enough translations to signify a next release the translations are ,merged to the add-on repo and the new version is released for this example it is 1.1.
The problems with this approach assuming that the 1.1 version contains only new translations that is there were no identified issues between 1.0and 1.1:

The version number is increased without a good reason.
Developer has to create a new release just to update translations - something which could easily be avoided with my second workflow, see below.
For some users lack of the translation to their native language may be a show stopper which in theory may cause some issues not to be identified due to smaller user base.



Workflow 2:


1. Developer requests review of his/her add-on.
2. When review passes the add-on is added to the development section and (if developer wishes so) to the translation system.
3. After some translations are created developer declares an add-on as stable, it is moved to the stable section and released as a 1.0 with all translations created until the release day.
The advantages are not only lac of problems with the first workflow, but also bigger user base - I assume translators are testing their translations and in turn the addon that is being translated.


Commends are appreciated.

--
Regards
Łukasz




 

Hi,
Note: at this stage, I recommend using Percentage Checker as a case study for the new proposed workflow, not as an exception so the community can learn from it.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Joseph Lee via Groups.Io
Sent: Thursday, December 26, 2019 7:52 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Percentage Checker #AddonRequestReview

Hi,
Ah, a pilot program, I see. If you wish to take that route, go ahead.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Lukasz Golonka
Sent: Thursday, December 26, 2019 7:40 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Percentage Checker #AddonRequestReview

Hello,

Looking at it from a perspective of an NVDA user who does not speak English can we really call the version without translations stable?
Unless there are any problems with my proposal I would like to proceed as follows in the percentage checker case:

1. Register it as a dev version when convenient.
2. At the same time register it in the translations system.
3. I'll wait lets say until the end of January and then would release version 1.3 as stable. I assume a month is ling enough for at least some translations to show up.


--
Regards
Łukasz

On Wed, 25 Dec 2019 10:06:28 -0800
"Joseph Lee" <@joslee> wrote:

Hi,
Personally, I tend to use the first workflow, although there are times when I do resort to waiting until things are stable before releasing a new version.

To place our discussion in context, here's what happens when we get translation requests:
1. A copy of your add-on repo is created on Bitbucket for the purpose of keeping an eye on translations. I and Noelia recently talked to the original brains behind translations workflow (Mesar Hameed) about unifying our workflow under GitHub.
2. A special repo named "mrconfig" is used to transport translations. First, the new add-on is registered, then a schedule is created to exchange translations between translators and Bitbucket repo.
3. The Friday after the add-on is registered for translations, translators are notified about a new add-on via a new entry in their language translation settings file (lang/settings JSON database). A language team (one or more translators) wishing to translate an add-on would say "yes" by setting the new add-on value to "1" and commit it via Subversion.
4. Every Friday after that (Thursday for some), messages from the new add-on are sent to translators, and translators would work on it and submit it. This will work for languages where translators said "yes" to translating the new add-on (not all language teams respond with 1).
5. In return, translations commit bot would gather translations for the add-on and commit it to the newly created Bitbucket repo under "stable" branch. This happens at the same time as new or changed messages being sent to translators (every Friday).
6. Add-on authors would then pull in latest translations from Bitbucket. You must create a remote pointing to Bitbucket repo, and pull in stable branch commits from there to yours (either master or stable branch).
7. When authors are ready, the new add-on is released.
8. When releasing a new version from stable branch, a copy of this work must be committed to Bitbucket repo's stable branch so translations workflow can pick up things here and there.

My issue with the proposed workflow is step 7, especially if we think about translations: different authors have varying definition as to what is stable, and for some, how many language translations are sufficient to make it into stable release (currently 20 to 30 language teams send add-on translations on a regular basis). This is one of the reasons why I advise authors to not worry about translations until an add-on is declared stable; another reason is "last minute pulling out" - that is, an add-on goes through translations with no stable release, and for some reason, the add-on gets pulled from community add-ons website (most recent case is Word add-on).

When it comes to maintenance steps, I usually follow a combination of "release early, release often" and "do not put everything in 1.0". The first is employed in add-on snapshots, and second is used when releasing a stable release, knowing that I can get feedback from people along the way. As for translations, I try my best to devote a release once every quarter (three months) or semester (six months) to localizations; for add-ons such as Windows 10 App Essentials which are governed by continuous delivery model, every release (monthly or so) includes localization updates, although I try my best to devote maintenance releases to localization updates on a regular basis.

I do see merit in letting translations be a part of version 1.0.

Hope this clarifies things.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io
<nvda-addons@nvda-addons.groups.io> On Behalf Of Lukasz Golonka
Sent: Wednesday, December 25, 2019 4:29 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Percentage Checker #AddonRequestReview

On Tue, 24 Dec 2019 13:27:05 -0800
"Joseph Lee" <@joslee> wrote:

Adding Percentage Checker to translations: usually I'd wait for the add-on to show up on stable add-ons section - speaking of which, if you say yes, I'll do just that on New Year's Day, given it was out there for five years.
I have to admit that I am quite new to the add-ons review/translations process but in my opinion this approach is not that great. To explain why I think it can be improved lets analyse two sample workflows.

Workflow 1 which I think is the currently used (please let me know if I misunderstood something):

1. Developer requests a review of his/her add-on.
2. Assuming that review passes the add-on is either registered as a development version, or promoted directly to the stable section.
3. after being declared stable and released with a given version number (lets say 1.0) it is being added to the translations system.
4. When some time passes and there are enough translations to signify a next release the translations are ,merged to the add-on repo and the new version is released for this example it is 1.1.
The problems with this approach assuming that the 1.1 version contains only new translations that is there were no identified issues between 1.0and 1.1:

The version number is increased without a good reason.
Developer has to create a new release just to update translations - something which could easily be avoided with my second workflow, see below.
For some users lack of the translation to their native language may be a show stopper which in theory may cause some issues not to be identified due to smaller user base.



Workflow 2:


1. Developer requests review of his/her add-on.
2. When review passes the add-on is added to the development section and (if developer wishes so) to the translation system.
3. After some translations are created developer declares an add-on as stable, it is moved to the stable section and released as a 1.0 with all translations created until the release day.
The advantages are not only lac of problems with the first workflow, but also bigger user base - I assume translators are testing their translations and in turn the addon that is being translated.


Commends are appreciated.

--
Regards
Łukasz




 

Hi,
Two things just occurred:
1. Percentage Checker dev version has been registered on community add-ons website.
2. Add-on files repo now contains Percentage Checker dev download link (key: perChk). I advise putting a "-dev" suffix to 1.3 version until translations come in.

I'll register Percentage Checker with Add-on Updater once stable version is released.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Joseph Lee via Groups.Io
Sent: Thursday, December 26, 2019 7:53 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Percentage Checker #AddonRequestReview

Hi,
Note: at this stage, I recommend using Percentage Checker as a case study for the new proposed workflow, not as an exception so the community can learn from it.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Joseph Lee via Groups.Io
Sent: Thursday, December 26, 2019 7:52 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Percentage Checker #AddonRequestReview

Hi,
Ah, a pilot program, I see. If you wish to take that route, go ahead.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Lukasz Golonka
Sent: Thursday, December 26, 2019 7:40 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Percentage Checker #AddonRequestReview

Hello,

Looking at it from a perspective of an NVDA user who does not speak English can we really call the version without translations stable?
Unless there are any problems with my proposal I would like to proceed as follows in the percentage checker case:

1. Register it as a dev version when convenient.
2. At the same time register it in the translations system.
3. I'll wait lets say until the end of January and then would release version 1.3 as stable. I assume a month is ling enough for at least some translations to show up.


--
Regards
Łukasz

On Wed, 25 Dec 2019 10:06:28 -0800
"Joseph Lee" <@joslee> wrote:

Hi,
Personally, I tend to use the first workflow, although there are times when I do resort to waiting until things are stable before releasing a new version.

To place our discussion in context, here's what happens when we get translation requests:
1. A copy of your add-on repo is created on Bitbucket for the purpose of keeping an eye on translations. I and Noelia recently talked to the original brains behind translations workflow (Mesar Hameed) about unifying our workflow under GitHub.
2. A special repo named "mrconfig" is used to transport translations. First, the new add-on is registered, then a schedule is created to exchange translations between translators and Bitbucket repo.
3. The Friday after the add-on is registered for translations, translators are notified about a new add-on via a new entry in their language translation settings file (lang/settings JSON database). A language team (one or more translators) wishing to translate an add-on would say "yes" by setting the new add-on value to "1" and commit it via Subversion.
4. Every Friday after that (Thursday for some), messages from the new add-on are sent to translators, and translators would work on it and submit it. This will work for languages where translators said "yes" to translating the new add-on (not all language teams respond with 1).
5. In return, translations commit bot would gather translations for the add-on and commit it to the newly created Bitbucket repo under "stable" branch. This happens at the same time as new or changed messages being sent to translators (every Friday).
6. Add-on authors would then pull in latest translations from Bitbucket. You must create a remote pointing to Bitbucket repo, and pull in stable branch commits from there to yours (either master or stable branch).
7. When authors are ready, the new add-on is released.
8. When releasing a new version from stable branch, a copy of this work must be committed to Bitbucket repo's stable branch so translations workflow can pick up things here and there.

My issue with the proposed workflow is step 7, especially if we think about translations: different authors have varying definition as to what is stable, and for some, how many language translations are sufficient to make it into stable release (currently 20 to 30 language teams send add-on translations on a regular basis). This is one of the reasons why I advise authors to not worry about translations until an add-on is declared stable; another reason is "last minute pulling out" - that is, an add-on goes through translations with no stable release, and for some reason, the add-on gets pulled from community add-ons website (most recent case is Word add-on).

When it comes to maintenance steps, I usually follow a combination of "release early, release often" and "do not put everything in 1.0". The first is employed in add-on snapshots, and second is used when releasing a stable release, knowing that I can get feedback from people along the way. As for translations, I try my best to devote a release once every quarter (three months) or semester (six months) to localizations; for add-ons such as Windows 10 App Essentials which are governed by continuous delivery model, every release (monthly or so) includes localization updates, although I try my best to devote maintenance releases to localization updates on a regular basis.

I do see merit in letting translations be a part of version 1.0.

Hope this clarifies things.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io
<nvda-addons@nvda-addons.groups.io> On Behalf Of Lukasz Golonka
Sent: Wednesday, December 25, 2019 4:29 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Percentage Checker #AddonRequestReview

On Tue, 24 Dec 2019 13:27:05 -0800
"Joseph Lee" <@joslee> wrote:

Adding Percentage Checker to translations: usually I'd wait for the add-on to show up on stable add-ons section - speaking of which, if you say yes, I'll do just that on New Year's Day, given it was out there for five years.
I have to admit that I am quite new to the add-ons review/translations process but in my opinion this approach is not that great. To explain why I think it can be improved lets analyse two sample workflows.

Workflow 1 which I think is the currently used (please let me know if I misunderstood something):

1. Developer requests a review of his/her add-on.
2. Assuming that review passes the add-on is either registered as a development version, or promoted directly to the stable section.
3. after being declared stable and released with a given version number (lets say 1.0) it is being added to the translations system.
4. When some time passes and there are enough translations to signify a next release the translations are ,merged to the add-on repo and the new version is released for this example it is 1.1.
The problems with this approach assuming that the 1.1 version contains only new translations that is there were no identified issues between 1.0and 1.1:

The version number is increased without a good reason.
Developer has to create a new release just to update translations - something which could easily be avoided with my second workflow, see below.
For some users lack of the translation to their native language may be a show stopper which in theory may cause some issues not to be identified due to smaller user base.



Workflow 2:


1. Developer requests review of his/her add-on.
2. When review passes the add-on is added to the development section and (if developer wishes so) to the translation system.
3. After some translations are created developer declares an add-on as stable, it is moved to the stable section and released as a 1.0 with all translations created until the release day.
The advantages are not only lac of problems with the first workflow, but also bigger user base - I assume translators are testing their translations and in turn the addon that is being translated.


Commends are appreciated.

--
Regards
Łukasz




Lukasz Golonka
 

On Thu, 26 Dec 2019 08:44:21 -0800
"Joseph Lee" <@joslee> wrote:
2. Add-on files repo now contains Percentage Checker dev download link (key: perChk). I advise putting a "-dev" suffix to 1.3 version until translations come in.
I've created 1.3-dev release on my GitHub repo.

 

Hi,
As a follow-up: later today 1.3-dev download link will be associated with the new add-on key. Thanks for doing this.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Lukasz Golonka
Sent: Thursday, December 26, 2019 9:32 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Percentage Checker #AddonRequestReview

On Thu, 26 Dec 2019 08:44:21 -0800
"Joseph Lee" <@joslee> wrote:
2. Add-on files repo now contains Percentage Checker dev download link (key: perChk). I advise putting a "-dev" suffix to 1.3 version until translations come in.
I've created 1.3-dev release on my GitHub repo.

Noelia Ruiz
 

Hi, I see that this add-on is on Bitbucket. Not sure if it's
registered on the translations system or if my help is needed.
I will be available this weekend. The next week I will go on holliday.
Let me know whatever is needed from my part.
I am testing the add-on and I like it.
Cheers

2019-12-26 18:36 GMT+01:00, Joseph Lee <@joslee>:

Hi,
As a follow-up: later today 1.3-dev download link will be associated with
the new add-on key. Thanks for doing this.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io>
On Behalf Of Lukasz Golonka
Sent: Thursday, December 26, 2019 9:32 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Percentage Checker #AddonRequestReview

On Thu, 26 Dec 2019 08:44:21 -0800
"Joseph Lee" <@joslee> wrote:
2. Add-on files repo now contains Percentage Checker dev download link
(key: perChk). I advise putting a "-dev" suffix to 1.3 version until
translations come in.
I've created 1.3-dev release on my GitHub repo.