Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Problem
- String concatenation madness in hook_help():
$output .= '<h3>' . t('Uses') . '</h3>'; $output .= '<dl>'; $output .= '<dt>' . t('Creating aliases') . '</dt>'; $output .= '<dd>' . t('Users with sufficient <a href="@permissions">permissions</a> can create aliases under the <em>URL settings</em> section when they create or edit content. Some examples of aliases are: ', array('@permissions' => url('admin/people/permissions', array('fragment' => 'module-path')))); $output .= '<ul><li>' . t('<em>member/jane-smith</em> aliased to internal path <em>user/123</em>') . '</li>'; $output .= '<li>' . t('<em>about-us/team</em> aliased to internal path <em>node/456</em>') . '</li>'; $output .= '</ul></dd>'; $output .= '<dt>' . t('Managing aliases') . '</dt>'; $output .= '<dd>' . t('The Path module provides a way to search and view a <a href="@aliases">list of all aliases</a> that are in use on your website. Aliases can be added, edited and deleted through this list.', array('@aliases' => url('admin/config/search/path'))) . '</dd>'; $output .= '</dl>';
Goal
-
Sanity?
<h3>Uses</h3> <dl> <dt>Creating aliases</dt> <dd>Users with sufficient <a href="{{ 'admin/people/permissions#module-path'|url }}">permissions</a> can create aliases under the <em>URL settings</em> section when they create or edit content. Some examples of aliases are: <ul> <li><em>member/jane-smith</em> aliased to internal path <em>user/123</em></li> <li><em>about-us/team</em> aliased to internal path <em>node/456</em></li> </ul> </dd> <dt>Managing aliases</dt> <dd>The Path module provides a way to search and view a <a href="{{ 'admin/config/search/path'|url }}">list of all aliases</a> that are in use on your website. Aliases can be added, edited and deleted through this list.</dd> </dl>
(sorry, I'm not up to speed with twig template syntax)
Details
- Obviously, a couple of things to figure out...
- Extracting (static) translatable strings out of twig templates.
- Making that |url filter work.
- ...more...
Comment | File | Size | Author |
---|---|---|---|
#32 | Screenshot 2014-02-01 16.40.16.png | 65.43 KB | larowlan |
#32 | Screenshot 2014-02-01 16.25.31.png | 65.83 KB | larowlan |
#32 | help-twig-1918856.1.patch | 6.42 KB | larowlan |
Comments
Comment #1
Fabianx CreditAttribution: Fabianx commentedThat is a great idea.
In general that would favor an approach like:
http://twig.sensiolabs.org/doc/extensions/i18n.html
Code: https://github.com/fabpot/Twig-extensions/blob/master/lib/Twig/Extension...
where the result is not run through gettext, but through t() instead.
Only the filtered URLs would need to be set as vars at the beginning. The rest would be quite straightforward though the question remains how to split it nicely up.
Maybe a new extension based on i18n that takes line-endings into account?
Comment #2
andypostAt least the results on hook_help() should have different context and I prefer to allow alterability
Comment #3
andypostTagging
Comment #4
Fabianx CreditAttribution: Fabianx commented#2: What do you mean with alterability?
Comment #5
andypostMeaning that contrib should have ability to add own lines to core's help text
Comment #6
sun@andypost: That's not possible right now either, and I haven't ever seen that use-case to begin with.
The proposal here just intends to change the source of the big HTML string that is generated. It's still a big HTML string though.
Comment #7
jhodgdonThis seems like a good proposal, as the main help page would certainly then be easier to write. But is it realistic to think we could get this done in core for D8, given that we would need it to (a) work for displaying all the existing help texts for core modules and (b) be translatable?
Comment #8
joelpittetFYI, these issues should help:
#2049241: Add support for language options to the Twig {% trans %} tag extension
#1927584: Add support for the Twig {% trans %} tag extension
Comment #9
larowlanTwig folks: Is this possible yet?
Comment #10
joelpittet@larowlan I can't see why not. We have all the details in the summary figured out. We haven't used twig environment outside of hook_theme() definitions. If this *can* become a theme hook it would be fairly straight forward. If not, we need to find a place to put the template and have the twig engine just render a template... also not really too hard.
Comment #11
sunOf course, I'd naturally prefer a README.md.twig as opposed to a help.html.twig file ;)
Grepping Google, I found:
https://github.com/aptoma/twig-markdown
https://github.com/KnpLabs/KnpMarkdownBundle
https://github.com/geta6/Twig-Markdown
@Crell additionally mentioned that Sculpin uses something similar:
https://sculpin.io/
The gist is that we want to pre-process or post-process the markdown formatted text, so we're able to inject
{{ url() }}
(or however that works) into twig-enhanced .md files.But of course, killing hook_help() [pages] in favor of help.html.twig files would be true awesomeness as a first step already. :)
Comment #12
jhodgdonInstead of actually writing the hook_help() for each module as a Twig template file, which at this point would require a lot of work in the Help module that I don't think anyone is doing, would it be possible instead to define a Twig template for help?
I am not a Twig expert but it seems like it could have input variables that would be
- about: array of paragraphs of text for the About section
- uses: array where each item is a Uses item
==> uses items each are an array with element 'title' (the title of the item) and 'text' (array of paragraphs of text)
Then you could do something like this in your hook_help():
Can this be done in Twig?
Comment #13
jhodgdonThe problem with the ideas that were previously proposed here (original proposal, and #11 as well) is that someone would have to totally rewrite the Help module in order to use them. Instead of using hook_help(), it would need to read some other file and use that, and besides that we would need to modify localize.d.o or the code that it uses, so that it would make this new file translatable.
It is very late in the D8 cycle for this type of change to be accepted, I think? And I've seen so many proposals for redoing the help system die a horrible death.
In contrast, the idea of #12 would just require someone to write a single Help twig template that would print out help in our standard format, and then we'd need to convert the existing hook_help() text to call theme() instead of concatenating in the HTML tags as we are currently doing. This doesn't require any redo of the help system so I think it would be viable to do at this stage.
Comment #14
sun@jhodgdon: That proposal is very different to the concrete proposal here, so should go into a separate issue.
The entire point of this proposal here is what you describe as "minor" but actually is a major DX clusterfuck and the primary reason for why (literally) only Drupal core cares for proper help module pages, but no one else, as outlined in the issue summary:
Comment #15
jhodgdonOK, changing the title then -- I think several people who have commented here have missed the point partially or completely, and thought it was really about making a single Help twig template -- which you have just explained is not within the scope of this issue.
Given that, I think this issue is a non-starter at this point for Drupal 8 and should be pushed to Drupal 9. But I do not wish to start any issue wars so I am not changing the version myself. The Help module for 8 currently has no maintainer; that person or one of the branch maintainers would probably be the logical person to make that decision.
Comment #16
markhalliwellFirstly, this is a feature request and secondly, this definitely is an API change (regardless if it's just moving it to templates). Also, degrading the priority to normal... it's just a normal request to clean up old crud (hell, could even really be a task for that matter).
FWIW though, I'd be willing to help work on this (along with anyone else willing). #1927584: Add support for the Twig {% trans %} tag extension definitely lands us the ability to translate large blocks of text inside a template. I think perhaps it would benefit us to at least look at https://drupal.org/project/advanced_help. We don't have to use anything really, just take a gander.
As far as an actual implementation though, I would strongly recommend we go for a generic auto-discovery of a
README.html.twig
file in the root of each project for the following reasons:README.html.twig
. People don't have to go searching for it.README
orREADME.txt
file. A simple rename, maybe add a some markdown twig tags around it to convert and voilà... easily converted help doc./help
) for specific twig files could allow us to leverage structure:README.html.twig
INSTALL.html.twig
CONFIGURE.html.twig
API.html.twig
Idk, just an idea...
Comment #17
jhodgdonJust a question... Why Twig? Twig files are not all that readable until they're processed by Twig, and they're not (I think) much more writeable by non-programmers (e.g., documentation team members) than the current hook_help() template (which at least some non-programmers have managed to pick up, but not many.
I would rather close this as Won't Fix and start a new issue with a markdown or other proposal, which would have the advantage of having text that is at least readable in its unprocessed form, and easier to edit. Since we're being strict here about the issue scope, I'm assuming that anything that doesn't match the original issue here is out of scope and should be opened as a separate issue.
I just don't really see what doing this in a Twig template really buys us. Maybe we need a proper issue summary outlining what the actual problems are with the current system (not just someone's aesthetics), so we can see which ones would be solved by going to this particular system? Or we could open up one of the many many many past issues that tried to redo the help system in some more rational way... and failed to get anywhere for various reasons.
Comment #18
markhalliwellBecause a Twig would allow advanced maintainers the flexibility of:
Or the simplicity and readability of converting existing README.txt files into:
Quite simply, it's leveraging existing (well aside from putting in the markdown parser) template processing (twig tags, filters, functions, etc...).
No, this issue should remain open to discuss this more.
Comment #19
andypostAnd twig should allow contrib modules to inject own lines for code templates?
Comment #20
joelpittetI'd rather see the format that works best for the people usually writing these help. If markdown in a README.md is easiest to work with then cool. We can add a page for it then loading that file into the content for a routed help page. I'd rather not force people writing these help pages in twig templates when the focus is more on writing the content and not the markup.
Comment #21
larowlanCan we support translation with markdown?
I don't think so but happy to be wrong.
Comment #22
joelpittetNot to my knowledge:( Also would be happy to be wrong.
Comment #23
jhodgdonIs everything in a Twig template automatically translated though -- I thought you had to wrap text in Twig in something to get it to be translatable? That would make writing the Twig template much more complicated than the examples shown here, thereby I think negating a lot of the supposed benefits of this approach.
Comment #24
joelpittet@jhodgdon you are correct about twig + translate. And I agree with you and also curious how translation was dealt with and do we need to here too. Maybe some markdown parser changes?
Comment #25
jhodgdonI'm not sure what you're asking for in #24. So far, this idea is just a conceptual idea, not code, so translation hasn't been dealt with at all.
In the existing hook_help() code, translation is dealt with by calling the t() function and passing the help text in.
Comment #26
joelpittet@jhodgdon in twig you can translate things two ways, depending on how you want it to look in the markup:
With the |t filter
With the trans block
Partly stolen from @Mark Carver's blog post
http://getlevelten.com/blog/mark-carver/drupal-8-twig-templates-and-tran...
Comment #27
jhodgdonGood information.
It would be good to see a sample of a more realistic Twig template for a module help page to see what this would look like, keeping in mind that we don't want the HTML tags to get into the translatable strings (which is why we have all the so-called "ugly concatenation" that this issue is trying to get rid of).
Comment #28
batigolixWould YAML files not be more suitable for storing the help texts? They are used for Tour tips, which have an similar purpose: providing documentation for the UI
(https://drupal.org/developing/api/tour)
The HTML markup for help texts is always identical (exactly as defined inhttps://drupal.org/node/632280)
Comment #29
larowlanFYI, I'm working on an example. Need to brush up on |url functionality first though
Comment #30
larowlanActually url might be blocked on #2073811: Add a url generator twig extension?
Comment #31
jhodgdonRE #28 - apparently this issue has a very narrow scope and is only available for considering the specific case in the issue summary: individual Twig templates for each help file. So probably we would need to file a separate issue if we want to use YAML files.
Comment #32
larowlanSo this uses url() but as #2073811: Add a url generator twig extension points out, we need a method to allow url() to use route names, but this will do for now.
So sample overview.html.twig is in attached patch.
With this approach, if hook_help returns an array with template and variables key, then that template is sought in the /help folder of the module.
This converts help_help for admin/help to use a twig template.
Screenshot before and after.
Comment #33
sunThanks for trying it out, @larowlan! Interesting start.
I wonder: What if the entire template was wrapped into
{% trans %}
?What's the realistic chance that only one original/English text fragment in a help text is changed, as opposed to the whole text? — And, if that happens, does it make any sense in the first place to show a help page that is 95% translated, but has some English fragments in between, because those have changed?
In other words, this:
Comment #34
jhodgdonI don't think we want the entire help, with all the tags, translated. That was the entire reason we put all the concatenation in the current hook_help. If that isn't a concern, we can just have a multi-line HTML string embedded inside the hook_help() and get rid of the Twig templates (which I think will be easier to deal with).
Comment #35
jibranReally awesome work @larowlan. Let's create a meta and finish this up.
Comment #36
joelpittetI'm leaning towards sun's approach with the trans around the whole thing because it will easier to read and cleaner looking and instead of translating the individual strings they could just translate the whole block of HTML, like as if they were translating the body field. The tags in the translation would be like that, would that be ok?
Also nice job @larowlan for the proof of concept. We should probably consider removing the .html.twig extention in the template definition just to be consistant with how we define templates in the theme system?
Comment #37
larowlanI used single calls to t instead of trans to preserve/reuse existing translations, but I prefer the big chunk for DX too.
Comment #38
joelpittetThat's a good call @larowlan. Maybe Gábor Hojtsy could jump in on this or anybody on the multilingual initiative for best plan of attack?
Comment #39
batigolix1) The example used in #32 and #33 is very much not representative for the help text that are currently in Drupal core. It would be better to use for example the Color module. All the hook help texts have the same structure with an About and a Uses section.
2) I still think it makes more sense to first discuss/think about what are the possibilities for this kind of documentation as mentioned in #11 and #28. Maybe that should be done in a separate issue.
3) The proposal in #32 doesnt seem a big DX gain compared to the current situation. It seems that there still is a lot of code, quotes and brackets that impede writing a bit of documentation
4) Most hook_help implementations contain texts for different paths. See for example the node module. Would these all go together in one twig file?
Comment #40
larowlan1) Yes, color would be a cleaner example
2) Happy to postpone this on something else.
3) agreed, but we're kind of bound to what translation dictates
4) separate files
Comment #41
sunThis issue here is specifically about the main module help page text only. A module's "README", if you will.
All of the other hook_help() return values are beyond the scope of this issue. First and foremost, the other help texts are not BLOBs that happen to contain HTML, but instead, small fragments of help text only; most often not even involving HTML markup. In fact:
hook_help()
is a weird legacy construct to begin with. The help text is attached to (A) a particular route and/or actually (B) to a block (HtmlFragment
).→ Typical use-case for plugins.
@Crell just happened to mention in IRC that all of these should simply be Tour plugins, but yeah, the use-case, processing, and output of help texts might be different, dunno.
In any case, all of that presents a crystal clear difference to the main module READMEs that are being targeted in this issue:
Let's proceed with experiments here. It would be awesome to see a variant of #32 that demonstrates #33 in action :)
Comment #42
jhodgdonThanks for all the enthusiasm...
Since apparently discussing the goals of this proposal and possible alternative ways to satisfy them is out of scope, can someone please open a separate issue to discuss this? I am not sure what the point of this issue is and I think we need to discuss what the goals are and the best way to satisfy them before we embark on this one specific proposal. That hasn't been done.
We also need to bring in two important stakeholders:
a) The people who actually write and review the hook_help. The way to find the people who are currently active is on the many current "update the hook_help" issues. There's a meta at: #1908570: [meta] Update or create hook_help() texts for D8 core modules
b) Translators, localize.d.o etc.
Until that discussion takes place, this whole effort is premature and I've already been shot down once on this issue for bringing it up, so we need a separate issue. Can someone who knows what the goal of this one is please file a separate issue where we can discuss other ideas? And can we postpone work on this one until that has been done please?
Comment #43
sun#32 + #33 are the goal and the scope of this issue. We have Twig in core, so we should leverage it.
In essence, the architecture of our current module help pages pretty much means this in reality:
Regarding A), I'm not sure why I/we do not count as "someone who actually writes and reviews hook_help()"...? — Fact is, I'm used to write polished READMEs, but every time I want or have to touch hook_help() for a module, the DX makes me cry and give up. → Whenever possible, I avoid to write or touch hook_help(). Certainly not in anyone's interest.
The overall adoption rate and quality of hook_help() in contributed modules appears to confirm that there is a problem. The only valid implementations I've ever seen are the ones in Drupal core, which alas, needs an entire armada of contributors to keep them in shape. The assumption is that hook_help() is simply too hard and unnatural to use and implement; the idea of concatenating (1) translatable strings into (2) random [HTML] markup (3) in PHP code doesn't make much sense in the first place.
Regarding B), sure, this change would certainly need an adaption for the potx extractor script (that also powers localize.d.o). — Although given that the
|t
and{%trans%}
filters already exist in HEAD, that does not present a new or custom requirement. → Only the potential change of wrapping the whole markup (instead of text fragments) would need evaluation.Bottom line: We can do better. This proposal is certainly not the only possible option, of course. But for the sake of focusing on the concrete experiment and proposal here, other options should be discussed in different issues. :)
The idea for this proposal was born one year ago already, around the time when Twig was originally committed to core and after the first template file conversions had happened. Given some other Twig explorations that I've recently seen and discussed with @mortendk and others at DrupalCamp Vienna, the basic idea of "Actually, let me manually produce the output for this specific page here please" appears to be (somewhat) in line with those considerations even.
Long story short: The concrete idea and proposal here is to explore whether we can replace the main help pages of modules with Twig templates (because they have little in common with hooks and even less so with PHP in general). Let's keep on experimenting to see whether we can get readme.html.twig to work in a nice way. (And if/when that works, we could proceed to explore options for the most natural way, README.md.)
Comment #44
jhodgdonWow, sorry for even asking.
Comment #45
Gábor HojtsyI'm *really* concerned on behalf of translators with this syntax proposed above by @sun:
Just the immediate reasons that come to mind:
All-in-all I think this puts too much on the translators shoulders and also opens up several possible problems that the individual strings are designed to avoid. The individual strings are designed so that if one changes, not all get outdated. They also lack structural markup, so the developer can change that + the translator cannot break it. And finally using t() placeholders the security of the string is much more ensured than what I envision happening here.
Comment #46
joelpittet@Gábor Hojtsy re: #451 & 2 the hope would be that translators wouldn't touch the twig templates or need to know them. The content will be stored just like
t('hello !name')
etc would be stored in that proposal.{% trans %}
maps to thet()
function in PHP.Comment #47
Gábor Hojtsy@joelpitett: how would the grand {% trans %} block deal with the if/comment, etc. syntax in the text it contains then?!?
Comment #48
joelpittetOh didn't noticed that, I don't think that can be in there... trans I believe has a limited token set, if not enforced I'm sure we can... but same as
t('tests ' . (($is_true) ? 'one may be tracked' : 'probably won't work').' more text');
currently get's handled.Comment #49
joelpittetcomments are ignored. (translation happens on the generated string in the database same way t() in templates does in D7)
Comment #50
Gábor Hojtsy@joelpiettet: so the generated text would be slightly different based on how the if/endif evaluated? So translators would need to translate the complete text in slightly different ways multiple times?! Still confused how this is an improvement.
Comment #51
jhodgdonjoelpittet: The problem is with the alternative where we would use {% trans %} for the entire text as one chunk. This would put the entire text plus markup plus some Twig {} things into one translation string.
The problem with that is that it is relatively easy for a translator to mess something up, and then the Twig template and markup and stuff wouldn't work.
Which is why we usually try to keep markup out of translation strings, in general. Given that Gabor has just confirmed this, I think we'd need to translate each line and not use the "one chunk as a big thing to translate" alternative.
Which again brings up the question of what this is really buying us, and whether this is really easier for anyone to deal with than the current method of doing hook_help().
So... Can I ask again, could we please have a discussion about the problems that are attempting to be solved here (with them being in the issue summary and not buried in the discussion), and with permission for all alternative solutions able to be discussed? If not here, in another issue?
Comment #52
jhodgdonOK I've just started a separate discussion on how best to solve the problems of this issue:
#2188753: Get rid of hard-coded markup in hook_help() implementations
Feel free to continue the discussion there, propose alternatives, add to the "problems" section, etc.
Comment #53
lostkangaroo CreditAttribution: lostkangaroo commentedHaving updated a fair share of the hook_help() for D8 I can see where some of the ideas presented here could be considered improvements and I would support many of these would the time be available. However we should be focused on wrapping up the code base rather than determining something is wrong, ripping out and redoing a large portion of work that takes time due to lengthy and necessary review.
Twig files seem like the natural progression to hook_help() but we are looking at incorporating a yml for help.module to read per additional module to provide structure for the cases in the current hook_help or additional twig templates. An added benefit of this would be that help text could be available while a module is disabled. The help yml could be simply module_name.help.yml and structured
This way we can combine the ability to use twig templates and keep structure at the same time. It does create more files to maintain per module which actually deters DX to me personally more than the current hook_help system.
Either way this is by far a D9 issue at this point in the game.
Comment #54
jhodgdonRE #53 - better to discuss on the other issue, see #52.
Comment #55
joelpittet@Gábor Hojtsy it may not be the solution for this hook_help but the "improvement" is not needing to write every line as a string and instead translate the entire block of HTML(think translating a WYSIWYG body field). That may not be the best approach here but that is the purpose of {% trans %} to make t('string !var', array(...)) easier to write in HTML while still mapping directly to it. It has little in the way of magical powers that t() doesn't do because it's the same function being called when the twig file compiles to PHP.
Comment #56
Gábor Hojtsy@joelpittet: trans is not news to me, I think you are missing my point. See @jhodgdon in #51 explaining some of the same things that I explained or #45 on why this is several steps back for translators. Using a big trans block is NOT an improvement for translators on *any* level.
Comment #57
sunI'd like to better understand the concerns that have been raised. This is what I've heard:
Is that correct or not, or is something missing?
(1) was an error in the example snippet only; instead, I think the %trans% filter tag would end before control structures and be re-opened/re-started in the inner (and subsequent outer) body.
In case (2) is really a hard blocker (i.e., we cannot and we do not want to trust translators to produce raw but safe HTML), then we need to rethink here.
Now, if that is the case, I'd actually recommend to skip the current incarnation that involves raw HTML and directly hop to the more advanced experiment: README.md.
That is, because Markdown is (1) not raw HTML but yet (2) a clearly defined syntax and markup language.
More specifically, we do not even need Twig to resolve our two primary requirements:
Links to other routes/URLs.
Markdown:
→ Markup Preprocessor
A relatively simple Markdown preprocessor/filter is able to identify links that are using route names and automatically convert them into URLs, before the actual Markdown markup processing is executed.
Translatable chunks of text strings (and only text strings).
→ Raw string extractor + preprocessor.
Piggy-backing on the Markdown standard syntax: Disregarding the Markdown-Extras extension, the entire markup language of the standard Markdown syntax is based on plain-text, whereas (block) formatting is exclusively expressed via well-defined line prefixes.
As an example:
↓
Pretty simple to extract. And likewise, pretty simple to inject/rewrite.
Comment #58
Gábor Hojtsy@sun: I think you missed two points from the list in #57:
1. All other pieces of text in Drupal uses HTML markup. If there is extra twig markup included, then translators need to learn that. This is also true for Markdown markup. That some source strings use HTML links while others use Markdown links sounds like a recipe for mistakes to me.
2. Long chunks of text are a problem because even small typo changes in the source invalidate all translations. This is to some degree a tooling problem, but even with tooling it is lots of work to make sure translators fix the right things and spot all changes. Shorter strings invalidated is less work to redo translations (if you have a 3 para help text and fix a typo in the source translators only need to re-translate the short snippet where the typo was fixed, not all 3 paras again).
Comment #59
John_B CreditAttribution: John_B commentedposted in error - sorry
Comment #60
John_B CreditAttribution: John_B commentedComment #61
jhodgdonComment #62
joelpittetJust a suggestion, we could maybe do something like
file-name.help.twig
. Where the entire document is sent for translation instead of the little bits and pieces?Comment #63
andypostMaybe better to use
route_name.help.twig
then?Comment #64
joelpittet*.help.twig is an file extension suggestion not a route name. We've not done that yet but just a wild thought for the problem.
Comment #65
Fabianx CreditAttribution: Fabianx as a volunteer commentedThere is the better proposal to put help into CMI, which also solves the translation bit ...
Comment #66
joelpittet@fabianx cmi would make it hard to mark up help for presentation wouldn't it?
Comment #67
jhodgdonI've filed a new meta issue to collect all the problems with the current help system and discuss the best route to fixing them; this issue is being added as Related there:
#2592487: [meta] Help system overhaul
One note on this one: on a different issue, it was brought up that we probably want each paragraph of help to be a separate string. See the new meta for details on this.
Comment #68
catchDoesn't look like this is the current direction of #2592487: [meta] Help system overhaul so moving out of the active queue.
But also if we changed this, it could happen in a minor release with a bc layer for hook_help().
Comment #71
jhodgdonSee also #2592487: [meta] Help system overhaul
Comment #74
andypostThere's 2 competing approaches but only one have patch
The main issue with help/docs stored in files is a way to pass routes & render relative links in UI
Better to start with design #2516902: Introduce a visual hierarchy to the help page.
Comment #78
jhodgdonAt this point, the planned patch for Help Topics looks a lot like this idea. So, I think we can now close this as a duplicate of #2920309: Add experimental module for Help Topics and also #3041924: [META] Convert hook_help() module overview text to topics. If not, feel free to reopen. :)