Page MenuHomePhabricator

wgLogo should be globally Wiki.png
Closed, DeclinedPublic

Description

Handling logo changes through bugzilla and requiring shell access is a bit long. Instead we could set $wgLogo to Wiki.png for ALL wikis, shell access will no longer be required and communities will be able to change it quickly.

Task 1:
On new wiki creation, upload a default Wiki.png file and protect it. This can be handled by a script, and surely need an update of our wiki creation documentation.

Task 2:
Look at all wgLogo, contact the communities and ask them to switch to Wiki.png. Or we could use a script which move the existing logo, protect it and leave a redirect.


Version: unspecified
Severity: normal

Details

Reference
bz26993

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:15 PM
bzimport set Reference to bz26993.
bzimport added a subscriber: Unknown Object (MLST).
hashar created this task.Jan 27 2011, 9:04 PM

bugs wrote:

We used to have a large percentage of the logos set to $stdlogo, but this was changed when the v2.0 Wikipedia logos were rolled out. So...

Task 0.5: ask the Usability Team if they're ready for us to move all of the v2.0 logos to the local wikis so that they can be managed via Wiki.png again instead of Commons.

(In reply to comment #0)

Task 1:
On new wiki creation, upload a default Wiki.png file and protect it. This can
be handled by a script, and surely need an update of our wiki creation
documentation.

New wikis should already have a logo when they're requested, so we shouldn't need to upload just a default -- we can upload the real thing. I'm pretty sure that the language committee has "create a logo" on their pre-bug checklist.

This bug is very closely related to bug 24078.

Huji added a comment.Feb 17 2012, 5:05 PM

I don't agree with the solution suggested here, because if a project decides to disallow local uploads (and rely on a shared repository of images), then handling logos will become an issue (example: bug 34476).

A better approach, in my humble opinion, is to have a MediaWiki message dedicated to the image path. It can contain a reference to a file (e.g. "File:Wiki.png") in which case MediaWiki will automatically find the find (locally or on a shared repo) and use it, or it can contain a URL (starting with http://, https:// or //).

(In reply to comment #3)

I don't agree with the solution suggested here, because if a project decides to
disallow local uploads (and rely on a shared repository of images), then
handling logos will become an issue (example: bug 34476).

A better approach, in my humble opinion, is to have a MediaWiki message
dedicated to the image path. It can contain a reference to a file (e.g.
"File:Wiki.png") in which case MediaWiki will automatically find the find
(locally or on a shared repo) and use it, or it can contain a URL (starting
with http://, https:// or //).

Unless we steal this bug, though, this is a separate a MediaWiki feature request.

Huji added a comment.Feb 17 2012, 9:10 PM

(In reply to comment #4)

(In reply to comment #3)

I don't agree with the solution suggested here, because if a project decides to
disallow local uploads (and rely on a shared repository of images), then
handling logos will become an issue (example: bug 34476).

A better approach, in my humble opinion, is to have a MediaWiki message
dedicated to the image path. It can contain a reference to a file (e.g.
"File:Wiki.png") in which case MediaWiki will automatically find the find
(locally or on a shared repo) and use it, or it can contain a URL (starting
with http://, https:// or //).

Unless we steal this bug, though, this is a separate a MediaWiki feature
request.

Yes, and I'm sorry that I wasn't clear enough in my comment; what I'm trying to suggest here is to move this bug to MediaWiki product bugs, and fix it here.

(In reply to comment #3)

A better approach, in my humble opinion, is to have a MediaWiki message
dedicated to the image path. It can contain a reference to a file (e.g.
"File:Wiki.png") in which case MediaWiki will automatically find the find
(locally or on a shared repo) and use it, or it can contain a URL (starting
with http://, https:// or //).

A long-term goal is to _remove_ configuration from the MediaWiki namespace. This would be a step in the opposite direction.

This bug would be solved by a proper configuration interface. ^demon says such a configuration interface is slated for May 2012. Probably makes sense to wait for that.

(In reply to comment #3)

I don't agree with the solution suggested here, because if a project decides to
disallow local uploads (and rely on a shared repository of images), then
handling logos will become an issue (example: bug 34476).

A better approach, in my humble opinion, is to have a MediaWiki message
dedicated to the image path. It can contain a reference to a file (e.g.
"File:Wiki.png") in which case MediaWiki will automatically find the find
(locally or on a shared repo) and use it, or it can contain a URL (starting
with http://, https:// or //).

We can simply use CSS for that.

I agree with MZMcBride above in comment #6:

A long-term goal is to _remove_ configuration from the MediaWiki namespace.
This would be a step in the opposite direction.

I believe that it would be best only to have localisation messages in the MediaWiki namespace, not configurations.

So that was not a so good idea after all. We want to be able to have per wiki logos as well as some pointing to commons. I am thus abandoning this bug.