Template talk:Extension

About this board

Archives 

/Archive 1


Version for Wikimedia Phabricator Day 1

1
Qgil-WMF (talkcontribs)

Supported MediaWiki version

9
Tgr (WMF) (talkcontribs)

The template defaults to using extjsonuploader data. That works well in most cases, but not for supported MediaWiki version, where the value in extension.json means the MediaWiki version required for the current (master) version of the extension, while the template field is supposed to mean the oldest supported MediaWiki version (for extensions using the release branch compatibility policy, at least). I wonder if leaving the field empty would be a better default.

Ciencia Al Poder (talkcontribs)

I think it would make sense to use the version information from extjsonuploader data only when the compatibility policy is set to master. Otherwise, the value should be specified manually.

Jdforrester (WMF) (talkcontribs)

The field is almost always meaningless; yes, there's a 10-year-old version of the extension that used to work with MediaWiki 1.12 but no-one is testing it and certainly no-one is supporting it. Maybe we should label the field "minimum MW required by development branch" and have a second field for "oldest currently supported branch" which can be set manually (but only to a non-obsolete version, i.e. minimum 1.35 right now)?

Tgr (WMF) (talkcontribs)

Presumably it was tested 10 years ago when it was used with 1.12; shouldn't that be enough? For extensions following the release branch model, which get snapshotted biannually together with MediaWiki, being able to see how far those snapshots go back is a nice convenience. Someone using an old MediaWiki version presumably doesn't care about support, or doesn't have a choice.

(I can see how the "supported MediaWiki version" terminology could be misleading for something very old that the maintainer, if there's still one, won't entertain fixes for, but that's my mistake, the infobox doesn't use that wording.)

And I don't think using the field for "oldest MediaWiki version for which there is a compatible extension version" would crowd out more useful information - you are supposed to install the extension from the release branch matching your core version, so knowing what older core versions the extension's development branch or latest stable is compatible with seems quite useless.

For extensions using the master compatibility policy, I agree leaving the current behavior (using the extension.json field) makes more sense.

Ciencia Al Poder (talkcontribs)

If the field is entered manually, it's often used to say what's the latest MediaWiki version where it has been tested. For example, unmaintained extensions may have an old value there and not work with the latest MediaWiki versions, or only support LTS versions.

Tgr (WMF) (talkcontribs)

"Latest MediaWiki version the extension is known to work with" is certainly more useful information than any of the alternatives mentioned above. The value pulled from extension.json isn't really useful for that purpose, though.

Jdforrester (WMF) (talkcontribs)

"Latest MediaWiki version the extension is known to work with" is certainly more useful information than any of the alternatives mentioned above.

If "known" we mean "tests pass", then for 99%+ of extensions that's just master.

Tgr (WMF) (talkcontribs)

"Known" would mean "someone tested the extension with this relase". The use case here is that someone adds (via extension.json or directly) something like "<= 1.35.0" (which at the time actually means 1.35-138), then 1.39 is released, drops deprecated features, which breaks the extension – knowing that the extension doesn't work with the latest MediaWiki release would be useful for more users than whether it can be made to work with 1.27 (or at least I'd hope so).

Jdforrester (WMF) (talkcontribs)

Then call it "last manually tested with"?

Reply to "Supported MediaWiki version"

Categorization of extensions supporting Composer

2
Kghbln (talkcontribs)
Kghbln (talkcontribs)

I changed the module to just show "Extensions supporting Composer" in both cases since I do not know how to get lua to print two categories.

Reply to "Categorization of extensions supporting Composer"

Getting the links to packagist back?

8
Summary by Kghbln

The links are back. :)

Kghbln (talkcontribs)

@Samwilson: Great change you did to the template today. Will make things easier. However one thing that got lost on the way was the direct link to the packagist page. Will be cool to get this back again.

Samwilson (talkcontribs)

@Kghbln: Oops sorry! Where are you seeing an error?

Samwilson (talkcontribs)

@Kghbln: Ah, it was the manual link! Fixed now.

I think generally the composer = line can be removed from extension infoboxes now.

Kghbln (talkcontribs)

Thanks for fixing. I was basically seeing this on all pages using the composer parameter. Yeah, for the extensions in Gerrit these can indeed be removed. Cheers

Samwilson (talkcontribs)
Kghbln (talkcontribs)
Kghbln (talkcontribs)
Kghbln (talkcontribs)
Reply to "Getting the links to packagist back?"
Samwilson (talkcontribs)

Should we add a link to the extension's help page (at Help:Extension:Foo) if that page exists, perhaps above the 'Example' row?

Jdforrester (WMF) (talkcontribs)

Perhaps? Mostly those links should be inside the main extension page's list of useful links, but it probably won't detract too much from the rest of the information in the box.

Samwilson (talkcontribs)

Yeah, I agree, the help pages should be linked in the main text too, but I feel like it'd also be useful to find them in the same place on every extension — similar to how Phabricator links are always at top right.

Samwilson (talkcontribs)
Kghbln (talkcontribs)

Currently a link to a help page is created unconditionally, i.e. every extension gets it even if there is no help page. Perhaps an ifexist check should be added to help the cause. This line is only needed if there is a help page available.

Samwilson (talkcontribs)

@Kghbln: Yes, good idea; done (also allowing the help param).

Kghbln (talkcontribs)

@Samwilson Looks good to me now. Thanks a lot. PS Admittedly yesterday I somehow overlooked your initial diff. Too late in the evening I guess.

Samwilson (talkcontribs)

@Proactive programming: thanks for your recent changes.

Although I like the idea of extensions being able to declare what versions of MW they work with, I'm not sure this info needs to be given over three rows in the infobox. One row, with a comma-separated list of MW versions supported, would suffice I think.

I also wonder if this could be a single new parameter, parsed as required in Module:Extension (or wherever) to e.g. add categories etc.

Tacsipacsi (talkcontribs)

I like this three-row design. When a new MW version comes out, simply a new row needs to be added, and one can see in a glance that the extension doesn’t officially support it (yet). Was it one row, it would be less clear that even though an extension supports a bunch of MW versions, they’re all years old. Also, it’s easy to drop MW versions no longer supported by Wikimedia (i.e. versions that themselves get no security updates anymore), so no longer relevant information doesn’t clutter the infobox.

That being said, I’m not against using one parameter for all versions in code, given that it’s still displayed in three rows as now (neither am I definitely for it, though); and I think categorization is a good idea. Some documentation would also be useful, especially specifying the valid values, which would be needed to implement categorization (as well as to make this part of the template translatable).

Samwilson (talkcontribs)

I think what I don't like about the three rows is just the repetition of 'MediaWiki'. Maybe it could be a single row for the label (e.g. 'MediaWiki compatibility') and three rows for the current supported versions. I think it should also come after the 'Compatibility policy' row, because it's pretty similar — or maybe before that one, as this new info is actually of more use to people looking to install an extension.

But yeah, however it looks, it's good to have this. Documentation is a must. I think it could also use the MediaWiki version information templates, and perhaps have 'stable', 'LTS', etc. shown next to each.

Samwilson (talkcontribs)

Oh I forgot: I think it'd also be worth investigating whether it wouldn't be better to add supported-versions information to extension.json, because then it's tied to the code and is more easily queryable from everywhere (and can be included in the template via Module:ExtensionJson.

Tacsipacsi (talkcontribs)

Unfortunately extension.json can’t be used here. Module:ExtensionJson contains the extension.json files only from the default Git branch (usually named master), while the extension may support other MW versions, for example on branches matching the supported versions’ branches. This information is not available in the module, and I don’t think it’s even possible to determine programmatically which branches are actually maintained.

For using a separate row for “MediaWiki”: I don’t mind it either way. By the way, there’s a row titled “MediaWiki” already, so we could even do something like this:

Extension
Release status: unknown
MediaWiki 1.25
1.36 Not formally tested
1.34 Not formally tested
1.33 Not formally tested
Kghbln (talkcontribs)

Yeah, who is supposed to fill the information? I have the feeling that this is the wrong solution for the right problem. I also think that the information should be fetched from code and not manually be added here. PS Currently it shows 1.36, 1.34 and 1.32 where it should be 1.36, 1.35 and 1.31. We also had the case in the past that only two branches were supported at a time.

Samwilson (talkcontribs)

The existing requires values in extension.json are allowed to accept a version range (like Composer does), so something like "MediaWiki": ">=1.32 <=1.35" is permitted (but doesn't seem to be used anywhere).

Kghbln (talkcontribs)

In other words. The information will be fetched from extension.json instead of requiring editing on this wiki which is good. I think these lines should not be shown if no extension.json is around. They will not be filled anyways or in rare cases at best.

Ciencia Al Poder (talkcontribs)

Note that extension.json may only support the latest stable branch because of compatibility issues with MediaWiki interfaces, but the extension may work and be tested with older versions if you choose to download the corresponding branch of an older MediaWiki release.

AFAIK, Module:ExtensionJson only reads extension.json from the master branch (which may list a still unreleased MediaWiki version as the minimum supported version, like it usually happens with VisualEditor)

Kghbln (talkcontribs)

Good point. Thus the module needs to read the info from the respective branch.

Samwilson (talkcontribs)

Module:ExtensionJson could be modified to include each branch's compatibility information. It'd take slightly longer to generate, but I don't think it'd be an overly difficult thing. It'd also only apply when compatibility policy is rel or ltsrel.

Samwilson (talkcontribs)

I think we should remove these new parameters until it's clearer where the data for them is coming from. We don't want extension maintainers to start adding the info, only to later be told it's going to come from extension.json.

@Proactive programming: you added these, what do you think?

Samwilson (talkcontribs)

extension.json requires.MediaWiki value

3
Samwilson (talkcontribs)
Kghbln (talkcontribs)

Cool. Appears to work fine. Just tested on the page of the VisualEditor extension.

Samwilson (talkcontribs)
Reply to "extension.json requires.MediaWiki value"

translate "MediaWiki x.xx Not formally tested"

4
Wladek92 (talkcontribs)

Hi all, Can someone make translatable the status of MediaWiki in this template, to fit with the current language of the translated page ?

Example : on page Extension:CentralAuth/fr MediaWiki 1.36 Not formally tested should appear translated as MediaWiki 1.36 non testé formellement

Christian 🇫🇷 FR (talk) 16:11, 28 June 2021 (UTC)

Tacsipacsi (talkcontribs)

See discussion about these parameters below.

Wladek92 (talkcontribs)

Already done before, but this topic is not related to the contents of the message but to the way to declare it translatable in the template (...difficult for me).

Christian 🇫🇷 FR (talk) 07:52, 29 June 2021 (UTC)

Tacsipacsi (talkcontribs)

But the approach taken there affects translation; only stable things should be made translatable. Furthermore, as I explained there, currently it’s not even possible to properly internationalize the parameter values. Making it half-translatable for the time being would mean that

  • translators need to come here twice, wasting their time, and
  • it may happen that the current text isn’t kept at all, wasting translators’ time even more.
Reply to "translate "MediaWiki x.xx Not formally tested""

Add Categories for other compat policies

1
Reedy (talkcontribs)

Allow translating "Expand"/"Collapse"

2
Akeosnhaoe (talkcontribs)

How do I translate the "Expand"/"Collapse" button text?

Akeosnhaoe (talkcontribs)

Nevermind, I see that it depends on the interface language.

Return to "Extension" page.