Last modified: 2013-01-30 12:34:08 UTC
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.
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.
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.
(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.
