Update help url registrations for Gramps 5.2 #1648
Conversation
Add help_url to Reports, QuickViews, Graphical Reports, Web Reports, built-in tools and debug tools. Commit on behalf of Emyoulation.
|
@emyoulation Please review PR carefully - it includes these changes from your master branch. |
|
Yes. It looks great! Thanks! Next, it looks like I need to go back and find where built-in Rules plugins are registered. |
|
This PR has translatable string changes which should be avoided in a maintenance release. |
|
@Nick-Hall Right, there are new strings. However, my understanding was that the new *_HELP strings contain part of a URL and wouldn't be translated. @emyoulation is that the intended usage? |
|
If my understanding is correct, these are translatable URLs that will add strings to the Weblate. Yes, that will ding the translation statistics. But if we do not have these help_urls for WikiContributor and translator (probably not developer since they can use the master branch) experimental purposes, then the documentation support for translators cannot evolve. There are a LOT of issues about WikiMedia translated anchors, page forwarding, and possible use of the Weblate glossaries with a MediaWiki plug-in. So that will need a lot of test data. |
|
Got it. Did not know that URLs were translated. Thanks for clarifying. Lmk if this needs to be rebased to another branch. |
|
That's a Software Architect call. |
|
We don't really want to translate links to wiki pages. For example, consider the English link:
The French link needs to be:
The page We don't need the user to translate the original link to:
In the past I have seen a translator translate such a link without knowing what they are doing. We end up with broken links. |
|
The complication with that is handling of Redirects in MediaWiki. appending the language after the anchor just disables the redirect AND drops the anchor. Redirects drop the anchor. And even if they did not, the Translators are not preserving the English anchor. To preserve the anchor on the redirect, I had to insert span ID in English, and insert the language redirection after the page URL rather than the anchor. This meant using the url: So the URL needs the language redirection in a weird place or the URL needs to be fully translated. There are multiple roadblocks to smooth translation of anchored help_url targets. So we need multiple options in order to work out the correct solution. At the very least, this requires building a Weblate URL glossary to find all the English target URLs and anchors in those URLs. With a checklist, we can assess the SCALE of the problem before deciding which solution has the least overhead. Right now, we know too little. |
Correct. We don't need the URL translated. Gramps can add the language code after the page and before the heading.
Yes. This is why I am hesitant to add more translatable URLs into a maintenance release. We could be making the problem worse. |
|
In that case, how about just grepping those .gpr.py files to eliminate the translation underscore for the help_url attribute and merging the vanilla URLs? |
|
That is certainly an option to consider for v5.3. We would have to think about how to handle non-wiki URLs though. |
|
Perhaps the help_urls could be merged into the master branch fairly soon? Then consistent GUI for accessing the wiki help links in the different plugin types might emerge from the 5.3 cycle? besides non-wiki URLs and addons, it could consider a relative link. Most of these GitHub hosted addons include a README.md with preliminary docs. And they convey to the local installation. We don't have any way to display markdown documents on the desktops. GitHub interprets the markdown to serve pure HTML though. |
Add help_url to Reports, QuickViews, Graphical Reports, Web Reports, built-in tools and debug tools.
Commit on behalf of Emyoulation.