Change Details

The core parser emits links to edit every section; right now we emit both 'edit' and 'edit source' links, but it (AIUI) depends on some user and wiki configuration as to how many edit links we emit, whether we emit links to visual editor, etc. But in any case, Parsoid needs to be compatible & emit these before it can replace the legacy parser for read views. This would (likely) be a post-processing pass, as the exact links emitted is user-dependent. It would also ensure we don't clutter/invalidate parser tests every time we decide to tweak how the section edit links look or what editor they link to, like the legacy parser does. A simple test case: https://en.wikipedia.org/wiki/User:Cscott/Parsoid_section_test Note that transcluded sections also have direct links to edit the page on the transcluded section. On the example page these look something like: https://en.wikipedia.org/w/index.php?title=User:Cscott/SectionTemplate&veaction=edit&section=T-1 Note that we don't currently make any guaranteees about content inside a transclusion. Properly emitting the above links would probably require us *not* to strip some Parsoid info from the transclusion and come closer to guaranteeing that the contents of a transclusion are a valid Parsoid document with its own `data-mw` and `data-parsoid` that can be interpreted to reconstruct the template tree. See {T269629}, {T260169}, and {T259824} (where DiscussionTools has to chase down recursive transclusions to find the "true" page holding a given discussion topic/reply/et).

The core parser emits links to edit every section; right now we emit both 'edit' and 'edit source' links, but it (AIUI) depends on some user and wiki configuration as to how many edit links we emit, whether we emit links to visual editor, etc. But in any case, Parsoid needs to be compatible & emit these before it can replace the legacy parser for read views. This would (likely) be a post-processing pass, as the exact links emitted is user-dependent. It would also ensure we don't clutter/invalidate parser tests every time we decide to tweak how the section edit links look or what editor they link to, like the legacy parser does. A simple test case: https://en.wikipedia.org/wiki/User:Cscott/Parsoid_section_test Note that transcluded sections also have direct links to edit the page on the transcluded section. On the example page these look something like: https://en.wikipedia.org/w/index.php?title=User:Cscott/SectionTemplate&veaction=edit&section=T-1 Note that we don't currently make any guaranteees about content inside a transclusion. Properly emitting the above links would probably require us *not* to strip some Parsoid info from the transclusion and come closer to guaranteeing that the contents of a transclusion are a valid Parsoid document with its own `data-mw` and `data-parsoid` that can be interpreted to reconstruct the template tree. See {T269629}, {T260169}, and {T259824} (where DiscussionTools has to chase down recursive transclusions to find the "true" page holding a given discussion topic/reply/etc). See also: {T270199}.

The core parser emits links to edit every section; right now we emit both 'edit' and 'edit source' links, but it (AIUI) depends on some user and wiki configuration as to how many edit links we emit, whether we emit links to visual editor, etc. But in any case, Parsoid needs to be compatible & emit these before it can replace the legacy parser for read views. This would (likely) be a post-processing pass, as the exact links emitted is user-dependent. It would also ensure we don't clutter/invalidate parser tests every time we decide to tweak how the section edit links look or what editor they link to, like the legacy parser does. A simple test case: https://en.wikipedia.org/wiki/User:Cscott/Parsoid_section_test Note that transcluded sections also have direct links to edit the page on the transcluded section. On the example page these look something like: https://en.wikipedia.org/w/index.php?title=User:Cscott/SectionTemplate&veaction=edit&section=T-1 Note that we don't currently make any guaranteees about content inside a transclusion. Properly emitting the above links would probably require us *not* to strip some Parsoid info from the transclusion and come closer to guaranteeing that the contents of a transclusion are a valid Parsoid document with its own `data-mw` and `data-parsoid` that can be interpreted to reconstruct the template tree. See {T269629}, {T260169}, and {T259824} (where DiscussionTools has to chase down recursive transclusions to find the "true" page holding a given discussion topic/reply/et)c). See also: {T270199}.