ht://dig is an exercise in pain. Please, please either:
(1) allow Google to index the mailing lists again
(2) add a search that isn't completely useless.
- d.
Also of course no-one on Project Wikispam ever bothered with userspace:
even blatant spam there survives miscellaneous for deletion if if just
contains one porno picture and the user raised it as censorship...
============
Gregory Maxwell wrote:
> On 4/27/07, Andrew Cates <andrew(a)catesfamily.org.uk> wrote:
>> You've mentioned that before and I gave you a more plausible explanation
>> (which was changing robots.txt on the "what links here" pages, which was
>> where all the google points and traffic on user space came from). But
>> hey, why listen or answer when you have your own theory and want to
>> stick to it.
>
> o_0 I don't know that I ever saw a spam-userpage that linked to
> anything internally.
>
>
>
Our handling of [[media:...]] links has the feel of a temporary solution.
In the absence of true media support, we give the user a direct link to
the file so that they can play it with an external application. Presumably
this was never meant to be a permanent syntax feature.
Now that we are edging closer to true audio and video support in
MediaWiki, it might be a good time to re-evaluate this syntax convention.
I'm making some architectural changes at the moment that will make it
easier to support audio and video in the core, on the same footing as
images. The question of syntax then becomes relevant.
We could add another prefix that plays audio or video inline in the
browser. But the thing is, "media" is a very good term for this operation,
and its current function will be made all the more confusing by
introducing a similarly named keyword that does what "media" should have
done in the first place.
What I propose is to introduce a new prefix called "download", which will
replace "media" for cases where downloading is really what is desired. For
example:
[[download:Foo.doc|Click here to download the text as an MS Word document]]
Wikimedia's text corpus can be transitioned to this syntax over a period
of time. Then the stage will be set to introduce media player features to
[[media:...]] style links. Backwards compatibility can be maintained for
file types with no currently defined media player.
Puns on putting the media back into MediaWiki have been studiously avoided
until this closing sentence.
-- Tim Starling
An automated run of parserTests.php showed the following failures:
This is MediaWiki version 1.10alpha (r21646).
Reading tests from "maintenance/parserTests.txt"...
Reading tests from "extensions/Cite/citeParserTests.txt"...
Reading tests from "extensions/Poem/poemParserTests.txt"...
18 still FAILING test(s) :(
* URL-encoding in URL functions (single parameter) [Has never passed]
* URL-encoding in URL functions (multiple parameters) [Has never passed]
* Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html) [Has never passed]
* Link containing double-single-quotes '' (bug 4598) [Has never passed]
* message transform: <noinclude> in transcluded template (bug 4926) [Has never passed]
* message transform: <onlyinclude> in transcluded template (bug 4926) [Has never passed]
* BUG 1887, part 2: A <math> with a thumbnail- math enabled [Has never passed]
* HTML bullet list, unclosed tags (bug 5497) [Has never passed]
* HTML ordered list, unclosed tags (bug 5497) [Has never passed]
* HTML nested bullet list, open tags (bug 5497) [Has never passed]
* HTML nested ordered list, open tags (bug 5497) [Has never passed]
* Fuzz testing: image with bogus manual thumbnail [Introduced between 08-Apr-2007 07:15:22, 1.10alpha (r21099) and 25-Apr-2007 07:15:46, 1.10alpha (r21547)]
* Inline HTML vs wiki block nesting [Has never passed]
* Mixing markup for italics and bold [Has never passed]
* dt/dd/dl test [Has never passed]
* Images with the "|" character in the comment [Has never passed]
* Parents of subpages, two levels up, without trailing slash or name. [Has never passed]
* Parents of subpages, two levels up, with lots of extra trailing slashes. [Has never passed]
Passed 493 of 511 tests (96.48%)... 18 tests failed!
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello!
You are receiving this email because your project has been selected
to take part in a new effort by the PHP QA Team to make sure that
your project still works with PHP versions to-be-released. With this
we hope to make sure that you are either aware of things that might
break, or to make sure we don't introduce any strange regressions.
With this effort we hope to build a better relationship between the
PHP Team and the major projects.
If you do not want to receive these heads-up emails, please reply to
me personally and I will remove you from the list; but, we hope that
you want to actively help us making PHP a better and more stable tool.
The final release candidate of PHP 5.2.2 was just released and can be
downloaded from http://downloads.php.net/ilia/. This RC introduces a
series of bug fixes to pre-existing issues with no significant
regressions been identified since RC1, so we are planning to proceed
with a final release within a week. Given that this is the case I
would like to ask everyone to test out this RC against their code to
ensure that no regressions were introduced. If you discover any new
issues please let me know.
In case you think that other projects should also receive this kinds
of emails, please let me know privately, and I will add them to the
list of projects to contact.
Best Regards,
Ilia Alshanetsky
5.2 Release Master
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)
iD8DBQFGMTK6LKekh381/CERAq8YAKCOsBqCeWhJtm9U6bxojYT4R9/35QCfVe9Y
LfII3YQ8Wbi3lsLM4wRs4l4=
=Gdei
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Due to an attacker mass-abusing accounts with weak passwords, passwords
that are the same as the username can no longer be used. Affected
accounts can reset their password by e-mail to something more secure.
Please report the change back to your various communities in case
someone needs help...
- -- brion vibber (brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGMSBWwRnhpk1wk44RAlqBAJoC6YMCK5qYfYhcyMWZPzh2XDLmOwCfQje3
lyq4jSE9wP+NrIBkDeomckg=
=oHa1
-----END PGP SIGNATURE-----
Since I have open sourced the wikix program, now anyone wanting the
images can download them directly from Wikipedia.
I am in process of restructuring the WikiGadugi site, so anyone wanting
the bittorrent downloads need to finish up this week,
as I will discontinue them shortly since folks now have the ability to
download them directly. The wikix program
is not very intensive on the main Wikimedia servers. The program is
setup to behave as several workstations, and it really
does not take that long to get the images.
To date, under ten folks have downloaded the entire image archive, so it
does not appear that there is that much interest.
Jeff
I've committed a change to MediaWiki's media file handling: modularisation
of file-type specific operations such as rescaling of images and
in-browser display. These modules are referred to as media handlers. As I
hinted in my post on the image/media/download pseudo-namespaces, this
change is intended to make it easier to implement support for audio and
video files in MediaWiki. With a few minor changes to the wikitext parsing
code and an extra media handler module, we should be able to support audio
and video in the core on the same footing as images.
This change also makes it much simpler to add extra image formats. Instead
of having special cases and if/elseif/else structures dotted throughout
the code, the relevant functions are delegated to a media handler
identified by MIME type.
Most of the old API has been retained for backwards compatibility. The
most significant function to be introduced is Image::transform(), which
transforms a media file with a handler-specific set of parameters. It
returns a MediaTransformOutput object, which contains methods for
in-browser display, as well as the data needed for remote or asynchronous
transformation.
Media handlers are a subproject of a larger project which has been
assigned to me, to change the architecture of the image backend. Basically
the idea is to get rid of NFS for local network image data transfer, and
to replace it with a private HTTP-based API. Early work for this API is in
the WebStore extension in svn.
In the MediaWiki core, this means abstracting local file operations. On
the server administration side, we intend to have a cluster of image
storage backends, possibly replicated and load balanced, instead of the
current single backend server. We're staying with file-based storage for
now. We intend on leaving the proposed filesytem layout changes until
after these backend architectural changes have been made.
These backend changes are definitely our first priority. But once the
backend changes are out of the way, here are some features I'd like to
think about:
* Embedded video and audio support, with asynchronous recoding into
different formats (say by polling the recode status with JavaScript)
* Support for large file uploads directly to the image backend servers,
probably using some kind of browser-embedded applet.
* Support for an arbitrary number of image repositories accessible from
each wiki, instead of the two currently offered by MediaWiki (commons and
local). Remote repositories like that in the InstantCommons proposal would
be one application. Fetching images from arbitrary wikis using an
interwiki-like syntax would also be a possibility.
-- Tim Starling
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
daniel(a)svn.wikimedia.org wrote:
> Revision: 21560
> Author: daniel
> Date: 2007-04-25 05:42:18 -0700 (Wed, 25 Apr 2007)
>
> Log Message:
> -----------
> introducing magic word {{USERLANG}}; This should fix a lot of problems for multilingual wikis.
>
I think it's problematic due to caching.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGL0+/qahN/0dU8mcRAkfxAJ0ZFYiklHAUQF4JvuuxjuUnZxRqKgCcCtHj
9gRfG1rZxOs8y1ChJjeZKf0=
=1nJF
-----END PGP SIGNATURE-----