Change Details

[As discussed with Denny just now.] ### A: Inside the JSON blob [no-one has done this] - i18n via either one big blob with inline language switching or lots of little blobs, one per language #### Pros - Conceptually simple - Quickish to implement - If one blob, allows for treating ZObjects like MW pages (categories, etc.) #### Cons - Storage size; maximum 2MiB blob size overall will mean hard to support lots of languages (300 languages x 2KiB of wikitext x 200% JSON expansion bloat cost ~= 1.2MiB of wikitext alone, taking much of the space; probably the effective limit) - Inefficient processing of heavy JSON blobs with wikitext that only the ZObject view renderer cares about, not the ZFunction processor, etc. - Fiddly to provide the editing experience users would expect. - Some things would have complex implementation vs. expectation issues. (What does {{DISPLAYTITLE}} do? What does __NOINDEX__ do? What does {{#REDIRECT}} do? Etc.) - Would need to re-implement big bits of MW (history/RC/…) and hook into others (parser functions, transclusion, …) - Re-using/extending the Translate extension not possible (no wikitext source page, no sub-pages, not concept of a "master" defintion) - Can't in future filter things out of watchlist/recent changes for alterations to languages the user doesn't care about. ### B: In a secondary wikitext MCR slot [see SDC for example implementation] - Assembled onto the view page by the page handler - One big blob with inline language switching #### Pros - Conceptually very simple - Quick to implement - One blob, allows for treating ZObjects like MW pages (categories, etc.) - Things that aren't the front-end renderer can just ignore the slot entirely (no need to cascade/execute updates to functions/implementations/etc.) - Storage size issues deferred to later (300 languages x 6.66 KiB of wikitext would be max) #### Cons - Large bits of MCR not yet implemented; we might need to build this ourselves, or we might avoid using any bits that aren't yet there. How would we know? - Fiddly to provide the editing experience users would expect. Would it be OK to provide an "edit" tab that only shows you the description and nothing else (like Category pages)? - Can't create/edit a page with both slots at once; would need to be two edits (see MCR use for UploadWizard), which is a bit icky - Can't do a slot for each language - Re-using/extending the Translate extension not possible (no sub-pages, not concept of a "master" defintion) - Can't in future filter things out of watchlist/recent changes for alterations to languages the user doesn't care about. ### C: As a parallel associated namespace wikitext page [no-one has done this] - Sort-of-semi-transclusion is assembled onto the view page by the page handler somehow - One big blob with inline language switching #### Pros - Native/expected editing experience for doc pages (they're just wikitext pages), e.g. VE - Things that aren't the front-end renderer can just ignore the parallel pages entirely (no need to cascade/execute updates to functions/implementations/etc.) - No need to fix this for everyone; we could do just enough to make it work for us, probably? - Storage size issues entirely gone (if anything, giving people too much rope…) #### Cons - Different/diverging edit history of doc + reality - There's a reason this RfC has been untouched for six years - So much of MW assumes namespaces exist as singletons (Special:) or pairs (Foo: and Foo_talk:); adding a third (ZObject:, ZObject_talk: + ZObject_doc:) will likely be a big source of on-going issues unless we upstreamed this into Core as a well-known, widely-used feature. ### D: As wikitext sub-pages of a non-wikitext page [no-one has done this] - Sort-of-semi-transclusion is assembled onto the view page by the page handler somehow - Re-using/extending the Translate extension potentialy possible (but how would we add the concept of a "master-for-now" defintion?) #### Pros - Should be easy enough - Native/expected editing experience for doc pages (they're just wikitext pages), e.g. VE - Things that aren't the front-end renderer can just ignore the sub-pages entirely (no need to cascade/execute updates to functions/implementations/etc.) - Easy to ignore /foo,/bar,/bang languages you don't speak from watchlist/RC/… - Storage size issues entirely gone (if anything, giving people too much rope…) #### Cons - Different/diverging edit history of doc + reality - Different/diverging edit history of doc in different languages - Some things would have complex implementation vs. expectation issues. (What does the transcluded {{DISPLAYTITLE}} do? What does __NOINDEX__ do? What does {{#REDIRECT}} do? Etc.) - MW assumptions about namespace content typing and how sub-pages work might be a challenge.

[As discussed with Denny just now.] ### A: Inside the JSON blob [no-one has done this] - i18n via either one big blob with inline language switching or lots of little blobs, one per language #### Pros - Conceptually simple - Quickish to implement - If one blob, allows for treating ZObjects like MW pages (categories, etc.) #### Cons - Storage size; maximum 2MiB blob size overall will mean hard to support lots of languages (300 languages x 2KiB of wikitext x 200% JSON expansion bloat cost ~= 1.2MiB of wikitext alone, taking much of the space; probably the effective limit) - Inefficient processing of heavy JSON blobs with wikitext that only the ZObject view renderer cares about, not the ZFunction processor, etc. - Fiddly to provide the editing experience users would expect. - Some things would have complex implementation vs. expectation issues. (What does {{DISPLAYTITLE}} do? What does __NOINDEX__ do? What does {{#REDIRECT}} do? Etc.) - Would need to re-implement big bits of MW (history/RC/…) and hook into others (parser functions, transclusion, …) - Re-using/extending the Translate extension not possible (no wikitext source page, no sub-pages, not concept of a "master" defintion) - Can't in future filter things out of watchlist/recent changes for alterations to languages the user doesn't care about. ### B: In a secondary wikitext MCR slot [see SDC for example implementation] - Assembled onto the view page by the page handler - One big blob with inline language switching #### Pros - Conceptually very simple - Quick to implement - One blob, allows for treating ZObjects like MW pages (categories, etc.) - Things that aren't the front-end renderer can just ignore the slot entirely (no need to cascade/execute updates to functions/implementations/etc.) - Storage size issues deferred to later (300 languages x 6.66 KiB of wikitext would be max) #### Cons - Large bits of MCR not yet implemented; we might need to build this ourselves, or we might avoid using any bits that aren't yet there. How would we know? - Fiddly to provide the editing experience users would expect. Would it be OK to provide an "edit" tab that only shows you the description and nothing else (like Category pages)? - Can't create/edit a page with both slots at once; would need to be two edits (see MCR use for UploadWizard), which is a bit icky - Can't do a slot for each language - Re-using/extending the Translate extension not possible (no sub-pages, not concept of a "master" defintion) - Can't in future filter things out of watchlist/recent changes for alterations to languages the user doesn't care about. ### C: As a parallel associated namespace wikitext page [no-one has done this] - Sort-of-semi-transclusion is assembled onto the view page by the page handler somehow - One big blob with inline language switching #### Pros - Native/expected editing experience for doc pages (they're just wikitext pages), e.g. VE - Things that aren't the front-end renderer can just ignore the parallel pages entirely (no need to cascade/execute updates to functions/implementations/etc.) - No need to fix this for everyone; we could do just enough to make it work for us, probably? - Storage size issues entirely gone (if anything, giving people too much rope…) - Able to protect ZObject only without protecting the documentation #### Cons - Different/diverging edit history of doc + reality - There's a reason this RfC has been untouched for six years - So much of MW assumes namespaces exist as singletons (Special:) or pairs (Foo: and Foo_talk:); adding a third (ZObject:, ZObject_talk: + ZObject_doc:) will likely be a big source of on-going issues unless we upstreamed this into Core as a well-known, widely-used feature. - See T12647 and T39865 ### D: As wikitext sub-pages of a non-wikitext page [no-one has done this] - Sort-of-semi-transclusion is assembled onto the view page by the page handler somehow - Re-using/extending the Translate extension potentialy possible (but how would we add the concept of a "master-for-now" defintion?) #### Pros - Should be easy enough - Native/expected editing experience for doc pages (they're just wikitext pages), e.g. VE - Things that aren't the front-end renderer can just ignore the sub-pages entirely (no need to cascade/execute updates to functions/implementations/etc.) - Easy to ignore /foo,/bar,/bang languages you don't speak from watchlist/RC/… - Storage size issues entirely gone (if anything, giving people too much rope…) - Able to protect ZObject only without protecting the documentation #### Cons - Different/diverging edit history of doc + reality - Different/diverging edit history of doc in different languages - Some things would have complex implementation vs. expectation issues. (What does the transcluded {{DISPLAYTITLE}} do? What does __NOINDEX__ do? What does {{#REDIRECT}} do? Etc.) - MW assumptions about namespace content typing and how sub-pages work might be a challenge.

[As discussed with Denny just now.] ### A: Inside the JSON blob [no-one has done this] - i18n via either one big blob with inline language switching or lots of little blobs, one per language #### Pros - Conceptually simple - Quickish to implement - If one blob, allows for treating ZObjects like MW pages (categories, etc.) #### Cons - Storage size; maximum 2MiB blob size overall will mean hard to support lots of languages (300 languages x 2KiB of wikitext x 200% JSON expansion bloat cost ~= 1.2MiB of wikitext alone, taking much of the space; probably the effective limit) - Inefficient processing of heavy JSON blobs with wikitext that only the ZObject view renderer cares about, not the ZFunction processor, etc. - Fiddly to provide the editing experience users would expect. - Some things would have complex implementation vs. expectation issues. (What does {{DISPLAYTITLE}} do? What does __NOINDEX__ do? What does {{#REDIRECT}} do? Etc.) - Would need to re-implement big bits of MW (history/RC/…) and hook into others (parser functions, transclusion, …) - Re-using/extending the Translate extension not possible (no wikitext source page, no sub-pages, not concept of a "master" defintion) - Can't in future filter things out of watchlist/recent changes for alterations to languages the user doesn't care about. ### B: In a secondary wikitext MCR slot [see SDC for example implementation] - Assembled onto the view page by the page handler - One big blob with inline language switching #### Pros - Conceptually very simple - Quick to implement - One blob, allows for treating ZObjects like MW pages (categories, etc.) - Things that aren't the front-end renderer can just ignore the slot entirely (no need to cascade/execute updates to functions/implementations/etc.) - Storage size issues deferred to later (300 languages x 6.66 KiB of wikitext would be max) #### Cons - Large bits of MCR not yet implemented; we might need to build this ourselves, or we might avoid using any bits that aren't yet there. How would we know? - Fiddly to provide the editing experience users would expect. Would it be OK to provide an "edit" tab that only shows you the description and nothing else (like Category pages)? - Can't create/edit a page with both slots at once; would need to be two edits (see MCR use for UploadWizard), which is a bit icky - Can't do a slot for each language - Re-using/extending the Translate extension not possible (no sub-pages, not concept of a "master" defintion) - Can't in future filter things out of watchlist/recent changes for alterations to languages the user doesn't care about. ### C: As a parallel associated namespace wikitext page [no-one has done this] - Sort-of-semi-transclusion is assembled onto the view page by the page handler somehow - One big blob with inline language switching #### Pros - Native/expected editing experience for doc pages (they're just wikitext pages), e.g. VE - Things that aren't the front-end renderer can just ignore the parallel pages entirely (no need to cascade/execute updates to functions/implementations/etc.) - No need to fix this for everyone; we could do just enough to make it work for us, probably? - Storage size issues entirely gone (if anything, giving people too much rope…) - Able to protect ZObject only without protecting the documentation #### Cons - Different/diverging edit history of doc + reality - There's a reason this RfC has been untouched for six years - So much of MW assumes namespaces exist as singletons (Special:) or pairs (Foo: and Foo_talk:); adding a third (ZObject:, ZObject_talk: + ZObject_doc:) will likely be a big source of on-going issues unless we upstreamed this into Core as a well-known, widely-used feature. - See T12647 and T39865 ### D: As wikitext sub-pages of a non-wikitext page [no-one has done this] - Sort-of-semi-transclusion is assembled onto the view page by the page handler somehow - Re-using/extending the Translate extension potentialy possible (but how would we add the concept of a "master-for-now" defintion?) #### Pros - Should be easy enough - Native/expected editing experience for doc pages (they're just wikitext pages), e.g. VE - Things that aren't the front-end renderer can just ignore the sub-pages entirely (no need to cascade/execute updates to functions/implementations/etc.) - Easy to ignore /foo,/bar,/bang languages you don't speak from watchlist/RC/… - Storage size issues entirely gone (if anything, giving people too much rope…) - Able to protect ZObject only without protecting the documentation #### Cons - Different/diverging edit history of doc + reality - Different/diverging edit history of doc in different languages - Some things would have complex implementation vs. expectation issues. (What does the transcluded {{DISPLAYTITLE}} do? What does __NOINDEX__ do? What does {{#REDIRECT}} do? Etc.) - MW assumptions about namespace content typing and how sub-pages work might be a challenge.