Re: Request to have debugHelper added to the community site
On Wed, 28 Aug 2019, Noelia Ruiz wrote:
Hi, the space and ( is this: class GlobalPluginAh, yes I see.
Message without comments for translators can be found at line 61.I even looked through that, must have been half asleep at the time. That is the largest reason to release another patch version.
Also, you import:Actually, it is used everywhere there is a string. I require this add-on to be Python 2 and 3 compatible.
Please read this: https://python-future.org/unicode_literals.html#benefits
In addition, you may want to define a script to allow open theI didn't really think anyone would want to do that, but I can add it in next feature dev version since you suggested it.
In another message, you wrote:
I have installed your last release and the link provided to stable version in documentation doesn't work.It was missing a "v". It was also pointing to the previous release. The perils of doing a ten minute fix and release.
Also, when we register this for the translations system, we need a repo on Bitbucket and a stable branch for translated and translatable messages. ExeI have one there, but it needs to be updated with latest stable. I will do that and email you off list.
files forgettext are not needed in this branch, since the po files are built directly from the server, then I will remove them for this stable branch.I was planning to remove them anyway, and have Appveyor pull them from gists when building. I will set that up before sending you the bitbucket link. Which answers your other point: I am using Appveyor already. I have the appveyor.yml in its own branch of the project (deployment), so its development history doesn't clutter up the main git history. I was pushing a lot of changes to that for a while.
commit message. There is no need to add the new languages to the readme.md.Thank you, I wasn't going to. But I will shorten the changelog.
Other suggestion is that you may want to remove the encoding declaration if not needed, at the top of the global plugin. You can read this for more details:The linked document says:
Instead, include this as the first line of the file (only if the file contains
non-ASCII characters): # -*- coding: UTF-8 -*-
It doesn't contain non-ASCII characters now, but it may at some point, and it is intended to be Python 2 compatible. I think I should leave it in.
We do have it in buildVars.py, part of the Add-on Template, I believe for the same reasons.
If you want, we can mention your repo in the wiki too.Sure.
So here is the revised release, which addresses the rogue space, and fixes the translator comments and readme.
I will update the README URLs to the addons.nvda-project.org ones after they are working (after this release).
Thank you again for your advice and the code review.