Page MenuHomePhabricator

Adding "license-name" to $wgExtensionCredits requires COPYING to be in wikitext
Closed, ResolvedPublic

Assigned To
Authored By
Kghbln
Jun 18 2014, 7:32 AM
Referenced Files
None
Tokens
"Mountain of Wealth" token, awarded by Kghbln."Mountain of Wealth" token, awarded by Ricordisamoa.

Description

I am quoting Nikerabbit as he observed this:

"When the 'license-name' key is specified, this file is interpreted as wikitext."

One solution is to convert the existing COPYING files into wikitext another one will probably be to both allow text as well as wikitext.

Whatever is done should probably be done for MW 1.23 LTS too.

Examples:

[1] https://www.mediawiki.org/wiki/Special:Version/License/CentralNotice

[2] http://dev.translatewiki.net/wiki/Special:Version/License/Semantic_Forms


Version: 1.23.0
Severity: major

Details

Reference
bz66767

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 3:21 AM
bzimport set Reference to bz66767.
bzimport added a subscriber: Unknown Object (MLST).

One reason why I think that both wikitext and text should be supported is that a lot of external developers use GitHub as their repo. They offer a wide choice of license templates that may used to add the license as COPYING files to a repo. These templates obviously do not care about wikitext. I believe that in general only very few COPYING files will be in wikitext or will be converted into wikitext by their developers. Example [1] shows that even this fails to some extent.

Still wonder why linking via "license-name" breaks the display while doings so by default does not. Actually this may be regarded as the actual issue here. However, thumbs up for a fix to this.

Thank you for dealing with this. The commit message suggests that wikitext is no longer supported after the change. This would be equally bad for extensions which already migrated to wikitext to circumvent the issue. Also there are two branches out there 1.23 and 1.24 which only support wikitext. So in short: No. Additionally wikitext provides much more elegance if chosen which should not be dismissed out of the box.

Thank you for dealing with this. The commit message suggests that wikitext is no longer supported after the change. This would be equally bad for extensions which already migrated to wikitext to circumvent the issue. Also there are two branches out there 1.23 and 1.24 which only support wikitext. So in short: No. Additionally wikitext provides much more elegance if chosen which should not be dismissed out of the box.

Thanks for the feedback. Here is some background:
Many extensions were lacking structured license information (see here for details), so I decided to add it. However, before the Gerrit change I linked above was merged, adding "license-name" to extensions' credits would have caused the contents of COPYING/LICENSE files to be parsed as wikitext. Given that the great majority of such files were in plain-text format, that the Free Software Foundation does not publish an official wikitext version of the GNU GPL, that the GNU GPL is not freely editable, and that the current wikitext version of the GNU GPL as found in some repositories was poorly formatted, switching wikitext parsing off by default (and maybe adding a flag for the purpose later) made more sense to me than just adding a flag to disable parsing.

1.23 and 1.24 shouldn't be an issue as long as third-party users install extensions suited for the MediaWiki version they're using.

What would the ultimate solution look like IYO?

Thank you for your detailed reply.

Currently the ultimate solution would be to allow using wikitext or plain-text at choice since extensions already migrated to wikitext during the past eight months. These now face the same issue but in an inverted way since wikitext cannot be displayed in plain-text properly. But this ultimate solution will have to be implemented now to stay the ultimate solution (see below).

The valid argument I see for not allowing wikitext is that the vast majority of extensions is and will be using plain-text. This is why the original implementation forcing into wikitext appears to be very wrong when looking back now.

Allowing only plain-text is indeed acceptable if MediaWiki sticks to this in future. So extensions will have to migrate back now and have stability in this matter. However allowing both in some future would be unfair to them after having changed this twice. Assuming that plain-text is the chosen format I am closing this as resolved. I believe that this is in line with the commit message and the arguments provided here.

Cheers and thank you for clarification.

Plain text is no good format for the reader, but IMHO the status quo (only plain text) is better than the status quo ante (unofficial wikitext versions of the GPL, plain text interpreted as wikitext, missing "license-name"s).
If anyone comes up with a way to have official formatted license texts (HTML?) this task can be reopened.

Plain text is no good format for the reader ...

That's what I meant with more elegance when I was referring to wikitext. The future will tell but I guess it will not be an immediate one.