Page MenuHomePhabricator

Create an Extension for using Codex components in wikitext pages
Open, Needs TriagePublic

Description

Feature summary (what you would like to be able to do and where):
There have been several discussions on how to use Codex styles in wikitext. It seems to me that the basic needs should be satisfied by an extension with which it is possible to create the main components of the Codex: Button, Card, Label, Message, SearchInput (aka MediaWiki-extensions-InputBox), Tabs.

Benefits (why should this be implemented?):
This will allow communities to create more uniform designs in an easy way.

Related:

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
CCiufo-WMF renamed this task from Create Codex extension for wikitext pages to Create an Extension for using Codex components in wikitext pages.Feb 23 2024, 7:14 PM
CCiufo-WMF subscribed.

While the Design-System-Team doesn't plan to focus on this any time soon, I think it's something to consider for the future so I'm going to move it to our roadmap parking lot.

CCiufo-WMF added a project: Epic.
CCiufo-WMF changed the subtype of this task from "Feature Request" to "Task".

Does it need to be an extension? Since codex is part of mediawiki core, I think it would be reasonable to put in core.

Or maybe this can be declined in favour of T361497. I'm not sure why there needs to a way to insert icons directly through the parser instead of just using them as normal images.

Does it need to be an extension? Since codex is part of mediawiki core, I think it would be reasonable to put in core.

Or maybe this can be declined in favour of T361497. I'm not sure why there needs to a way to insert icons directly through the parser instead of just using them as normal images.

As a user, I want to have easy access to the basic forms provided by the codex for styling wiki pages. Without having to know scripts and constantly update styles.

Not sure what you mean by that? Rendering images from commons is basic wiki syntax and doesn't require knowing scripts or updating styles.

Not sure what you mean by that? Rendering images from commons is basic wiki syntax and doesn't require knowing scripts or updating styles.

Have we got all icons on Commons and how often these icons are updated?

Not yet, but someone can upload them and it's trivial to write a bot to keep them up to date.

As for the icons, I agree, but it is impossible to recreate the other components of the codex in this way: https://doc.wikimedia.org/codex/latest/components/overview.html

Not yet, but someone can upload them and it's trivial to write a bot to keep them up to date.

Semantically there's a difference between "Show this named image from Commons" and "Show the current Codex icon for Foo". For example, Commons may have "Codex 1.0" and "Codex 2.0" icons in paralell (so the name will give you the 1.0 even if 2.0 is current), while a hypothetical parser function / magic word / builtin syntax / whatever will always give you what the current icon is. Whether Commons wants their copy of the Codex icons to be continuously updated in-place or differentiated by versioning the file names is up to the whim of the community on Commons and can change a lot over time.

Now whether the need for this, and the actual (vs. hypothetical) downsides if not available, are big enough to justify the cost of implementing and maintaining something like a parser function is a different question.

I did submit a patch to Core attempting to create a parser tag for Codex icons. But now that I see this task and hearing feedback from other contributors on Discord, I am debating whether it is better for this to be in the same extension as defined in this task, or if all the Codex tags should be defined in MediaWiki Core. If we do the latter, there is possibly (I don't know because I am still relatively new to contributing to MW) the option of unbundling later and putting into their own extension for backwards compatibility if it is decided to move on from Codex.

The question is whether all of these should be in an extension or in Core.