-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've listed a couple of installation and configuration-related issues
which affect a lot of people installing MediaWiki on hosting services:
http://leuksman.com/log/2007/06/27/some-installer-tasks/
They shouldn't be too hard for someone interested to handle, and I've
included some suggestions and at least one partial patch on the bugzilla
entries, in case anyone's interested in picking them up. :)
- -- brion vibber (brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGgqjTwRnhpk1wk44RAvT7AJ94tkDnqozPT98+FnZC+ZG+VeBGawCeOSHs
6WLPkcBwxNcV9GHBr107WQA=
=Plvp
-----END PGP SIGNATURE-----
Hi Andy and wikitech-l,
I was forwarded your message (by Evan here at Google) asking about Earth
parsing the {coord} template. I am a data engineer working on the Wikipedia
layer and hopefully can help get this question resolved.
We can make our parsing tools recognize the new template; however, we
definitely do not want our decision to support this template to be
misconstrued as an endorsement or ultimatum. So, we are wondering if it has
broad support within the community?
It looks like one of {coord}'s purproses is to consolidate the number of
templates available for geo-tagging articles and we are definitely excited
about that prospect. Do you know if there are efforts to get {coord} (or an
equivalent, 'standard' geo-tagging template) implemented in additional
language versions of Wikipedia?
Lastly, we are discussing a collaboration with geonames.org. They have done
a lot of great work parsing and conflating Wikipedia data. Perhaps they are
worth reaching out to as another project using the geocoordinate templates.
Apologies for taking a long time to be in touch.
Cheers,
Jason
---------- Forwarded message ----------
> From: Andy Mabbett < andy(a)pigsonthewing.org.uk>
> Date: Jun 2, 2007 3:34 PM
> Subject: Google Earth and 'coord' template
>
>
>
> Hi,
>
> I'm told you might be the person to assist with this, or to direct me to
> someone who can.
>
> Please do!
>
> Thank you.
>
> In "Wikitech-l" message < JUxoMwM$7IXGFw76(a)pigsonthewing.org.uk>, Andy
> Mabbett <andy-VPqQCyIUKlYeBxrm02tS/ekiAK3p4hvP(a)public.gmane.org> writes
>
> >Almost two months ago, User:GMaxwell undertook to arrange for Google to
> >read the new 'coord' template:
> >
> > <http://en.wikipedia.org/wiki/Template:Coord>
> >
> >when they parse the raw Wikipedia data for their Google Earth Wikipedia
> >layer.
> >
> >Unfortunately, he hasn't posted for some time (I do hope he's OK).
> >
> >Can someone else pick up that baton, please, or advise me who to
> >contact? Or perhaps even confirm that that's been done?
> >
> >Thank you.
>
>
> --
> Andy Mabbett
> * Say "NO!" to compulsory ID Cards: <http://www.no2id.net/>
> * Free Our Data: < http://www.freeourdata.org.uk>
> * Are you using Microformats, yet: <http://microformats.org/>
> ?
>
Hi.
I'm trying to install MediaWiki 1.10.0 on my server (PHP 5.2.2 + MySQL 4.1.22).
When creating tables I get this error message:
------------------
Generating configuration file...
# Database type: MySQL
# Loading class: DatabaseMysql
# Attempting to connect to database server as remoteuser...success.
# Connected to 4.1.22
# Database test_mediawiki_1_10 exists
# Creating tables...Query "CREATE TABLE `mediawiki_job` ( job_id
int(9) unsigned NOT NULL auto_increment, job_cmd varchar(255) NOT NULL
default '', job_namespace int NOT NULL, job_title varchar(255) binary
NOT NULL, job_params blob NOT NULL, PRIMARY KEY job_id (job_id), KEY
(job_cmd, job_namespace, job_title) ) TYPE=InnoDB " failed with error
code "Specified key was too long; max key length is 1024 bytes
(mydbserver)".
------------------
I also tried with MediaWiki 1.6.10 and got the same error message:
-----------
# Database type: mysql
# Attempting to connect to database server as remoteuser...success.
# Connected to 4.1.22
# Database test_mediawiki_1_6 exists
# Creating tables... using MySQL 4 table defs...Query "CREATE TABLE
`mediawiki_job` ( job_id int(9) unsigned NOT NULL auto_increment,
job_cmd varchar(255) NOT NULL default '', job_namespace int NOT NULL,
job_title varchar(255) binary NOT NULL, job_params blob NOT NULL
default '', PRIMARY KEY job_id (job_id), KEY (job_cmd, job_namespace,
job_title) ) TYPE=InnoDB " failed with error code "Specified key was
too long; max key length is 1024 bytes (mydbserver)".
------------
'localhost' (Apache+PHP) is not the same server as 'mydbserver' (mySQL).
Any suggestion? Thank you very much.
> > 1) [Logged in] users should be able to view the deleted article, if it
> > was not deleted due to copyright or legal issues. I believe there are
> > many articles that are being deleted that are still very educational
> > to the public, and I don't think it is in the educational best
> > interest of our public to ban someone's right to view a deleted
> > article.
>
> That brings up the question of what exactly the point of deletion is,
> then. Users can already get the text articles deleted for innocuous
> reasons from any number of friendly administrators, and if they don't
> know where to ask, that's something that the English Wikipedia should
> solve itself by editing the appropriate message.
Casual users don't even know who administrators are to ask them for
the article. The point of deletion is to delete the article, but if
people want to see the archive, then they can still see it, but they
realize it's not an "approved" Wikipedia article. As a compromise, we
could allow only those users who have previously edited the article to
be able to see its review process and former article easily. At the
very least, all users should be able to see that an article was
formerly deleted, so they don't waste their time starting to write a
new one.
> > 2) There should be direct links on the deleted page to the discussion
> > (and previous discussion if it was put up for AfD before), so people
> > can more easily understand why an article was deleted.
>
> Posting deletion logs was tried just now and changed, because it's
> ugly and because it partly defeats the point of deletion when it
> quotes the content right on the very page it was supposed to have been
> deleted from.
>
> Possibly it would be interesting to allow a custom message to be added
> to a deleted article by admins, without actually recreating the
> article.
So, a user returns from their two week vacation and finds their
article deleted. Even though a long process occurred where people
debated it, to their eyes it looks like the article just up and
disappeared for no reason. They have no way to go and even see why.
So then they'll see that the time they spent on Wikipedia was wasted
and reach the conclusion that "Wikipedia sucks." ... and in this case,
I would have to agree with them. If something was deleted, then
interested individuals should at least be given the decency to be able
to see the reasons why and a link to the deletion review process.
> > 3) Email auto-notification of articles on someone's watchlist of being
> > proposed for AfD.
>
> Hard to see how this would be implemented without a fair amount of
> special-case code being written specifically for the English Wikipedia
> or whatever.
This is really simple. IF article is up for deletion for more than 12
hours THEN email all users who have this article on their watch list.
I say more than 12 hours so that people can't use this to just spam
lots of users with inappropriate AfD status. This should work in all
Wikipedias, not just English.
I hope this clarifies my points.
Best wishes,
Chuck
Hello,
I am working on expanding the capabilities of the MimeMagic module to reliably detect a larger number of media formats as part of my project to implement widespread support for video files. My experimentation on different file types as well as the existing amount of code dedicated to fixing the mistakes of facilities like `file -bi` have made me conclude that it would be worthwhile to modularize all the special-case code and supporting mime.type and mime.info data devoted to particular file types. I have nearly completed a mini framework to do that, which I'll be asking for a critique of soon. As I finish it up, though, I'd appreciate some clarification about how mapping of the various mime types to a media type (ie "AUDIO" or "ARCHIVE") was intended to work. Specifically, I can't figure out what the intent behind the "MULTIMEDIA" category is. By it's name it would seem to be a catch-all category, and some of the mime types assigned to it like application/ogg seem appropriate...but other members like video/quicktime and video/x-msvideo seem much more well defined. Was that an error, or is there some other deep dark purpose behind the "MULTIMEDIA" category that I should be aware of?
I ask because I plan to improve the accuracy of MimeMagic->getMediaType by consulting appropriate modules when necessary, and want to know if it is correct to do so ONLY if the type of the file in question fits into the MULTIMEDIA category.
Thank you,
Mike
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
aaron(a)svn.wikimedia.org wrote:
> Revision: 23297
> Author: aaron
> Date: 2007-06-23 17:27:39 +0000 (Sat, 23 Jun 2007)
>
> Log Message:
> -----------
> *Add year/month selector to user contribs (bug 516)
I think instead of a filter, I'd rather see this work as a sort of "jump
to date X" tool. Paging across month/year boundaries would then work
cleanly, which would be rather nice.
Since we already do the paging by date, it shouldn't be too hard to
implement this way; basically it could just override the offset
parameter with a forced dir=prev.
Another detail note; it might be nicer to avoid using a hardcoded id and
name attribute on the selector. Since it's being implemented in a
generic library class, it would be prudent to leave the id/name
selectable, so the interface won't have to be broken when more complex
forms try to use more than one on a page.
- -- brion vibber (brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGgCnjwRnhpk1wk44RAo+zAKCPDzaCDlAKbubGl2+7POVroMUhtgCgxTgD
aHSfQIn1WFUWMLoGHUjzJwE=
=suHC
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
robchurch(a)svn.wikimedia.org wrote:
> (bug 10344) Don't follow a redirect after changing its protection level
[snip]
> - $wgOut->redirect( $this->mTitle->getFullUrl() );
> + $wgOut->redirect( $this->mTitle->getFullUrl( 'redirect=no' ) );
It would feel a little cleaner to me if the redirect=no is applied
conditionally, as we do after edits.
The majority of the time we'll be working on non-redirect pages, and
getting back the canonical URL always feels nicer.
- -- brion vibber (brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGgCsvwRnhpk1wk44RAjChAKCNPrZVHIl6op4bpKrEVVkjcFdl9QCgrHAc
QZjKTI5mjrGiDsTJTvN5xAg=
=iZtP
-----END PGP SIGNATURE-----
Hello devs,
thank you for your cooperation to disseminate information using Global
sitenotice.
We close the acceptance of candidates and endorsements for them at
23:59, UTC, today. Could you please erase the current message about
Election just at that time?
Thank you for your attention,
Cheers,
--
KIZU Naoko
Wikiquote: http://wikiquote.org
* habent enim emolumentum in labore suo *