Template talk:Extension

Jump to navigation Jump to search

About this board

Archives 

/Archive 1


Per SPDX license list 3.0 (28 Dec 2017) release

7
Summary by Liuxinyu970226

tracked at phab:T183858

Liuxinyu970226 (talkcontribs)

Those old SPDX IDs are deprecated in favor of some new, clearly defined IDs:

  1. GNU Affero General Public License v3.0 (AGPL-3.0), splitted to GNU Affero General Public License v3.0 only (AGPL-3.0-only) and GNU Affero General Public License v3.0 or later (AGPL-3.0-or-later)
  2. GNU Free Documentation License v1.1 (GFDL-1.1), splitted to GNU Free Documentation License v1.1 only (GFDL-1.1-only) and GNU Free Documentation License v1.1 or later (GFDL-1.1-or-later)
  3. GNU Free Documentation License v1.2 (GFDL-1.2), splitted to GNU Free Documentation License v1.2 only (GFDL-1.2-only) and GNU Free Documentation License v1.2 or later (GFDL-1.2-or-later)
  4. GNU Free Documentation License v1.3 (GFDL-1.3), splitted to GNU Free Documentation License v1.3 only (GFDL-1.3-only) and GNU Free Documentation License v1.3 or later (GFDL-1.3-or-later)
  5. GNU General Public License v1.0 only (GPL-1.0), replaced by GNU General Public License v1.0 only (GPL-1.0-only)
  6. GNU General Public License v2.0 only (GPL-2.0), replaced by GNU General Public License v2.0 only (GPL-2.0-only)
  7. GNU General Public License v3.0 only (GPL-3.0), replaced by GNU General Public License v3.0 only (GPL-3.0-only)
  8. GNU Library General Public License v2 only (LGPL-2.0), replaced by GNU Library General Public License v2 only (LGPL-2.0-only)
  9. GNU Lesser General Public License v2.1 only (LGPL-2.1), replaced by GNU Lesser General Public License v2.1 only (LGPL-2.1-only)
  10. GNU Lesser General Public License v3.0 only (LGPL-3.0), replaced by GNU Lesser General Public License v3.0 only (LGPL-3.0-only)
  11. Nunit License (Nunit), no replacement

What should we do per those changes?

Liuxinyu970226 (talkcontribs)

Note that they also re-added "GPLv1/2/3 or later" and "LGPLv2/2.1/3 or later" with new IDs (their old IDs are deprecated in version 2.0rc2):

  1. GNU General Public License v1.0 or later (GPL-1.0-or-later, was GPL-1.0+)
  2. GNU General Public License v2.0 or later (GPL-2.0-or-later, was GPL-2.0+) *The MediaWiki software is using old one!*
  3. GNU General Public License v3.0 or later (GPL-3.0-or-later, was GPL-3.0+)
  4. GNU Library General Public License v2 or later (LGPL-2.0-or-later, was LGPL-2.0+)
  5. GNU Lesser General Public License v2.1 or later (LGPL-2.1-or-later, was GNU Library General Public License v2 or later LGPL-2.1+)
  6. GNU Lesser General Public License v3.0 or later (LGPL-3.0-or-later, was LGPL-3.0+)
Legoktm (talkcontribs)

Probably we should add aliases for the old -> new, and at some point run a bot to migrate everything over. We're also going to need to update MediaWiki source code too, this will be fun!

I filed https://github.com/composer/spdx-licenses/issues/15 since that'll be the place to start on getting MediaWiki updated...

Kghbln (talkcontribs)

Meh, writing e.g. "GPL-2.0-or-later" instead of "GPL-2.0+" is not really an improvement besides making the obvious even more obvious. Do we want to change the string users have to add to the template or do we just change the module to display a different label for the same license?

Legoktm (talkcontribs)

Unfortunately, I've come across enough places where people just put GPL-2.0 when in reality it was -or-later. Hopefully this will fix that. I think in the beginning we should just change the text and accept both forms of the license, and once 3.0 becomes more widely used we can start updating existing pages to use the new version?

Kghbln (talkcontribs)

Sounds reasonable to me to do it like this. In the end it will be an extension by extension effort to check and amend the information. I am not sure if this change will provide an improvement since a lot of people just write GPL. Still there is hope for better awareness now. Moreover in case of uncertainty GPL-2.0 it is better to be added than GPL-2.0+, but that's another story.

Liuxinyu970226 (talkcontribs)
Reply to "Per SPDX license list 3.0 (28 Dec 2017) release"

Auto-updating based on extension.json

1
Bawolff (talkcontribs)

Just a heads up, I recently created a bot to auto-update Module:ExtensionJson, and want to experiment with auto-filling this template out based on extension.json data.

Reply to "Auto-updating based on extension.json"
Framawiki (talkcontribs)

Eg: take Extension:Newsletter

It would be great if we can have another section titled

Contributing

You can contribute to the extension by:

$ git clone ssh://<USERNAME>@gerrit.wikimedia.org:29418/mediawiki/extensions/Newsletter.git

Moved from phab:T165808 -- 01tonythomas

Tacsipacsi (talkcontribs)

This is an infobox, it’s not for short stories but for​ basic data. “Contributing” can be a section in the main text, or in a README file in the Git root.

Seb35 (talkcontribs)

I’m also enclined to be against such a change, at least in the current presentation of the infobox: I find there are already too much things in this infobox and it is already difficult to read. I find a general re-organisation of the whole infobox would be very welcome, perhaps removing some links and/or using pictograms for some links.

A step further about what Tacsipacsi suggests, perhaps a template Contribute could be created and transcluded in the page, something like Template:ExtensionInstall does for installation.

Reply to "Add a 'Contributing' section"
Shirayuki (talkcontribs)
Ciencia Al Poder (talkcontribs)

SOFIXIT?

Why not use always {{BASEPAGENAME}}? It should also work on english pages. You'll need also {{NAMESPACE}}.

Reply to "FULLPAGENAME"
Shirayuki (talkcontribs)

Are license names translatable?

Legoktm (talkcontribs)

Hmm, quickly looking at d:Q7603, some languages do have it translated, but many more don't and use the English version...

Shirayuki (talkcontribs)
Reply to "license names translation"

no headings for readme and changelog, the whole "Download" section.

2
SPage (WMF) (talkcontribs)

In Extension:PieceOfCode I gave the readme parameter a value, but it just appears as an unidentified link under Download. I assume the same is true for changelog. The easy fix would be to provide link text for each, same as "Browse source code"

But with all these links, you're not downloading anything., so none belong under a Download column! They're just links to files that probably reflect the latest code, and the infobox seems to conflate this with "snapshot". It seems there should be a separate infobox section for Project, with links in it for browse source, view changes, readme, and changelog.

Ciencia Al Poder (talkcontribs)

Agree, although many of those links are generated by templates ({{GoogleCodeDownload}}, in that example), which would make it difficult to break into different sections

Reply to "no headings for readme and changelog, the whole "Download" section."

what should mediawiki parameter represent?

4
SPage (WMF) (talkcontribs)

Template parameters include

mediawiki
required version of MediaWiki

but is this the earliest version of MediaWiki for which there's a branch of the extension, or the earliest version of MediaWiki on which the extension's latest master will work?

There seems to be consensus that instead of the "master" branch supporting old MediaWiki releases, developers on releases should use the version of the extension tagged for that release from Special:ExtensionDistributor.

SPage (WMF) (talkcontribs)

In a related hack, in {{ExtensionInstall}} when it displays "To users running MediaWiki 1.24 or earlier: The instructions above describe the new way ..." I think[*] I added

(To run an extension on an earlier release, you may need to download the version of it tagged for that release from Special:ExtensionDistributor.)

It's really a more general point.

[*] I don't know how to test templates using TNT and translation.

Ciencia Al Poder (talkcontribs)

Note that even users running MediaWiki 1.25 should download the version tagged for that, because incompatibilities may happen if the extension was adapted to use new features introduced on master. This warning should probably be on the Special:ExtensionDistributor page

Ciencia Al Poder (talkcontribs)

It may also be "the latest know MediaWiki version where this extension has been tested and is supposed to work"

Reply to "what should mediawiki parameter represent?"
Qgil-WMF (talkcontribs)
Kghbln (talkcontribs)

The way I currently handle it is that I archive extensions listed in Category:Obsolete extensions after there is not supported version of MW around which may be used together with the respective extension. So the information provided with the obsolete template is not really best fit. No objections having this status since we already have "unmaintained".

Reply to "Request: add status=obsolete"

Add parameter to indicate whether DB update is needed post extension installation

4
Peachey88 (Flood) (talkcontribs)
<Wikinaut> yvipanda: does it need to run update.php after installation ? (this is not mentioned on http://www.mediawiki.org/wiki/Extension:ShortUrl )
<Reedy> Yes
<Reedy> That's somewhat stndard practise
<Wikinaut> Reedy, standard, yes/no, then please modify the Template:Extension info box, so that "php update.php" needed yes/no can be quickly indentified

Kthx.

This post was posted by Peachey88 (Flood), but signed as Reedy.

Peachey88 (Flood) (talkcontribs)

Hi, having this parameter was a very good idea. However I suggest to remove the explanation "php update.php needed after installation" from display. I takes heaps of space. I think everyone may just click on the link which takes one directly to the documentation of the parameter and its implications. Cheers

This post was posted by Peachey88 (Flood), but signed as Kghbln.

Juliano (talkcontribs)

It was annoying me too, so I went ahead and removed the explanation. I do not like boolean yes/no information presented in infoboxes this way. Cheers,

Reply to "Add parameter to indicate whether DB update is needed post extension installation"
Peachey88 (Flood) (talkcontribs)

in the section "Content Parameters"->Types->Interface->special, the external link to the SpecialPage.php is broken. i am not sure where should it link to.

This post was posted by Peachey88 (Flood), but signed as Hoorayforturtles.

Reply to "Broken link to SpecialPage.php"