Use cases:
- tidy content (just a parse & re-serialize) without any flags, as a nodejs-only alternative to the Java service: T89331
- re-expand templates (all, or specific ones): T114409, T151720
- re-sanitize content
- re-wrap sections and re-build TOC metadata: T114072
- migrate to latest content version (by mime type): T104462
- possibly, update red link information: T39902
- Convert the language variant: T43716
Not all use cases would apply in all situations, but there might be use cases that would benefit from the ability to combine several modes.
Request format
The expected content format is indicated with an Accept header. The format applies to the pagebundle format overall, and versions are kept in sync with nested html, data-parsoid, section offset & later data-mw components. In line with the regular pagebundle format, each component has a format content-type provided as part of its sub-structure as well:
html: {
headers: {
'content-type': 'text/html; charset=utf-8; profile="https://mediawiki.org/wiki/Specs/DOM/1.2.1"'
},
body: '<html>...</html>'
}To indicate which updates to apply, the request for the /pagebundle/to/pagebundle/ end point will contain an updates property:
updates: { transclusions: true, // Could specify which templates later. media: false, // Could specific the exact image to update later. redlinks: { added: ['Some_Title_as_dbkey'], removed: [] } }