-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
MediaWiki 1.3.4 is a bug fix and security release. File uploads are now
tested for validity which should screen out Internet Explorer file type
autodetection cross-site scripting vulnerabilities and at least the
known instance of the so-called "JPEG virus".
This does not check any existing uploads, and may not catch everything
if you've disabled the strict file type checking. Upgrading is highly
recommended for any wiki allowing public uploads!
(Upgrading from the previous release should be a simple matter of
decompressing the updated files into place, if you have not altered the
originals. There are no database structure changes.)
Changes from 1.3.3:
* Fixed lots of template-related bugs, esp. for cases where template
variables are used for links, images, etc.
* Fixed transformation of page messages when viewing Special:Allmessages
* Handle "ISBN ISBN 1234" correctly
* Fixed warning on Category pages
* Fixed some bad error messages on login page
* Fixed history entry for initial main page on install
* Removed problematic { and } from legal title characters
* Strip leading blank from output in preformated text.
* Fixed problem when moving pages to titles with '#' in
* Optional $wgRawHtml for raw <html> sections. Use only on limited-
participation 'trusted' wikis, as it does not protect against
cross-site
scripting attacks. For security, this option can only be enabled if in
$wgWhitelistEdit mode.
* Fixed problem where pages which were created as a redirect following
a move never showed on Special:Randompage.
* Fixed line spacing on printed table of contents
* Allow links to pages with names of the form [[RFC 1234]]
* Fixed broken edit links being shown for sections from included
templates
* Verify that uploaded image files are of the claimed type.
Release notes:
http://sourceforge.net/project/shownotes.php?release_id=271359
Download:
http://prdownloads.sf.net/wikipedia/mediawiki-1.3.4.tar.gz?download
Wiki admin help mailing list:
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
Bug report system:
http://bugzilla.wikipedia.org/
Play "stump the developers" live on IRC:
#mediawiki on irc.freenode.net
- -- brion vibber (brion @ pobox.com)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFBWgNXwRnhpk1wk44RAnsfAJ0XpDjxiTud8E1/Tsi8s8Z+dwY+XgCeJYtC
TwrVDJlODia4N+1A01tC2N8=
=Kroa
-----END PGP SIGNATURE-----
From WikiCommons the following seem currently to be the most wanted
additions to Wikimedia Software:
1. The possibility to use images on commons directly on Wikipedia
2. Getting a thumbnail of an image in a category (and for non-images some
descriptive text) instead of just the page title on a category page.
Unfortunately, it does not seem like there are any active developers on
WikiCommons currently, so I am throwing this into the larger group in the
hope someone will be interested in programming them.
Andre Engels
Hello Brion
> Subject: [Wikitech-l] Upload limitations
> From: Brion Vibber <brion(a)pobox.com>
> To: Wikimedia developers <wikitech-l(a)wikimedia.org>
...
> For the moment uploads are limited to the default extension whitelist:
> 'png', 'gif', 'jpg', 'jpeg', 'ogg'. Other types of files can't be
> uploaded to the wikis until we expand it again, but files already
> uploaded remain accessible.
Please add SVG to the list of default-formats, so people can continue to
provide SVG-source for drawings. Thank you.
BTW: is there a chance that the extension for rendering SVG to PNG on
demand will be available anytime soon?
Regards,
Daniel
Hoi,
I have been working really hard checking the 4800 words that are in
nl:wiktionary and converting them to undercase when needed. This is a
big task because the nl:wiktionary has grown quite a lot. I am thankfull
that we have to do this now and not a few thousand words later. As I got
bored and wanted to do something else as well, I have created a
soundfile called nl-Nederlands.ogg. I created this using Audacity which
was recommended to me (thanks :) ).
Audacity saved it for me as an ogg file and I have uploaded it to
nl:wiktionary. To my amazement, it identified itself as
*afbeelding:nl-Nederlands.ogg* (afbeelding means image). I expected that
I would be able to hear it, but I get a message telling me that the
operating system does not know what to do with the format. I installed
the real player it does not know what to do with it, I tried the Windows
thingie, same fiasco.
I had a look at META to see if I could find anything about .ogg files;
nothing. So, I had to be "adventurous" (I hate being adventurous) and
found that a Media player called "Ashampoo" could do the trick where the
conventional stuff fails miserably. It does indeed not only play ogg files.
The listening part of the file in wiktionary is a joke. It does say
Afbeelding:nl-Nederlands.ogg
<http://nl.wiktionary.org/wiki/Afbeelding:nl-Nederlands.ogg> and when
you click it, you get a details screen while I expect to hear something,
On this screen it is not immediately obvious what to do but there is an
nl-Nederlands.ogg It
<http://nl.wiktionary.org/wiki/Afbeelding:nl-Nederlands.ogg> text. When
you press this, you finally get to hear a word; the pronounciation of
"Nederlands" spoken by me.
The reason why I use so many words is, because .ogg files are the
recommended sound files. I expect that when you select one it will not
say image but *sound*, and when I press it, that it will try to let me
hear something. After this I wanted to check what it does with .wav
files but, they are not allowed anymore :(
An other issue is that sound files are worthwhile resources for
wiktionaries; how better to demonstrate pronounciation ?? When a naming
convention is used like xx-word where xx is the ISO 639 code and word,
well the word, you will get thousands of files. It would be really good
if COMMONS was the place where these sound files are uploaded to.
Questions:
* How can I make the .ogg file execute immediately (without a detail
screen) ?
*When can I upload sound files to COMMONS so that every wiktionary can
share this and similar resources ?
<http://nl.wiktionary.org/wiki/Afbeelding:nl-Nederlands.ogg>* What can
we do to make it easier for people to use .ogg ? Having loads of them
helps as well !!
Thanks,
GerardM
A question came up during a discussion on the Chinese wiki. There are lots of pages on Chinese wiki that does not have interwiki links, that has counterparts. However, finding these pages are very difficult. What's the easist way to get a list of all pages that does not have any inter-language links?
The proposal were either to run a SQL query of some sort against the database, or run the interlanguage bot against the wiki and parse the result log.
Which is a better way? Also, if it is the SQL query, who will be able to help me with it?
Thanks in advance.
-Vina
Hi,
What are the implied rules of creating hyperlinks?
Let's assume I am reading the page....
http://en.wikipedia.org/wiki/MandrakeSoft
I have understood 2 things about links...
1) Red links don't contain any text.
2) External links are marked (a convention, I wish all websites should follow)
But I completely fail to understand why certain words are hyperlinked.
For e.g. in the following para why does the date January 27 is linked?
I clicked on that date and could not find anything related to the
current page i.e. MandrakeSoft.
MandrakeSoft operated under bankruptcy protection from [[January 27]],
[[2003]] to [[March 30]], [[2004]]. Despite its efforts to cut losses
and improve profits, MandrakeSoft was forced to file for protection
due to a series of quarterly losses.
Too much (and mostly unnecessary) hyperlinks makes me shy away from using wiki.
Thanks
Shantanu Oak
Spanish Wikiquote is lacking a complete translation into Spanish. The
more modern messages, which have been translated through the MediaWiki:
namespace in Wikipedia and Wiktionary, are untraslated.
Would it be possible to automatically update the LanguageEs.php file
with the contents of Special:Allmessages from Wikipedia or Wiktionary?
Thus there won't be the necessity to repeat the translation process. If
this isn't possible I might provide a manual translation of the last
version of this file.
Regards.
> Isn't this going to be a bit awkward when anyone changes a MediaWiki
> message, and finds that they can't switch non-local speaking users
> away from the default? I mean, sometimes things like "Current events"
> get turned into something significantly different, like Meta's "Goings
> on".
> But then, perhaps a site like Meta: or a "data-based project" could
> just have *all* languages as "supported variants" (is this going to be
> a setting somewhere?), and attempt to propogate any major changes
> across each of the /langcode sub-pages.
yes, that's doable on the technical level.
The purpose of only allowing content language to be modified through
the mediawiki namespace is to ensure a somewhat consistent user
interface across the different languge sites. Otherwise, if every
language can be changed by anyone, then someone visiting say en.wp
using fr as UI, may have rather different experience when visiting
de.wp using fr as UI, because people at the two sites decided to
modify fr differently.
>
> ----
>
> Ah! Bug alert: some MediaWiki messages/translations determine the
> target of links. Different languages default these links to different
> locations, so putting the TestWikipedia in German gives me a link to
> http://test.wikipedia.org/wiki/Hauptseite rather than
> http://test.wikipedia.org/wiki/Main_Page. Perhaps destinations like
> this need to be stored seperately in some global
> (language-independent) part of the MediaWiki: namespace, and
> referenced in the default translations for each language -
> : in LanguageDe.php "[[ {{MediaWiki:mainpage}} | Hauptseite ]]"
> : of course, for UI language == content language, "[[
> {{MediaWiki:mainpage}} | {{MediaWiki:mainpage}} ]]" gives the
> equivalent of the current system
> In short, the *text* of such links can be translated, but their
> *target* needs to reflect the actual location on this wiki, wherever
> it appears.
>
> I would have guessed this would affect namespace names as well (e.g.
> User:, User_talk:), but I can't find any instances of this being the
> case so far.
>
> --
> Rowan Collins BSc
> [IMSoP]
>
These are being fixed. I think I got the namespace names part right so
far:) The problem with 'mainpage' is due to a new patch to
SkinPHPTal.php, and has been fixed in cvs.
Please report similar issues to this thread or to bugzilla!
Also, if you write new code that need to use $wgLang, or need to call
wfMsg*, please take into consideration the difference between the UI
elements and the content elements. For example, if you want to make a
link to the mainpage, it should look something like this, roughly
speaking:
here is the <a href= wfMsgForContent('mainpage') > wfMsg('mainpage') </a>
--
zhengzhu
Testing the 1.4 CVS version (new installations and update installations)
I found that the Interface Language in User Preferences was set
(defaulted) to Africaans.
In my humble opinion, even when I understand this language a little bit,
fresh MediaWiki installations should come with a "(uninstalled yet -
please choose)" default interface language, proposed: English .
Tom