Hi
I released a new version of the Eclipse Wikipedia Plugin [1].
Changes:
* a new context-menu item in the editor for creating all files for a
given category [2].
* a first Export Wizard to convert Wikipedia articles into a single
PDF file [3].
The PDF creation depends on rendering the wikipedia article into a
complete xml compliant file in the first step.
In the next step, the internal iText PDF library [4] uses a SAX parser
to convert the HTML to PDF.
As this is not always possible for the plugins current Wikipedia to
HTML parser,
sometimes articles are not included in the pdf file.
Therefore the next step for a "better PDF output" is IMHO to improve
the internal parser
to handle all special cases for the Wikipedia tags.
I created some JUnit tests [5] which I would like to use to improve the parser.
Does someone has a list of typical "evil" Wikipedia syntax constructs
and how they should
be rendered in (x)html?
Is there someone on the list who knows the iText library and could
give some general hints
how to improve the PDF output
(i.e. best design for Chapters, Sections and internal links between the pages)?
[1] http://prdownloads.sourceforge.net/phpeclipse/phpeclipse.community_tools_1.…
[2] http://www.plog4u.org/index.php/Using_Eclipse_Wikipedia_Editor:Download_a_W…
[3] http://www.plog4u.org/index.php/Using_Eclipse_Wikipedia_Editor:Export_to_PD…
[4] http://www.lowagie.com/iText
[5] http://cvs.sourceforge.net/viewcvs.py/phpeclipse/org.plog4u.wiki.test/src/o…
--
Axel Kramer
http://www.plog4u.org - Wikipedia Eclipse Plugin
hello,
all projects will be offline at some point today while routine network
maintenance is being performed. this is not expected to last more than an
hour or so.
apologies for any inconvenience...
kate.
These are three patches for the just-released MediaWiki 1.4rc1.
The first two should be un-controversial, I think.
* A typo in language/Language.php ("dismbiguations" instead of
"disambiguations")
* Change "FROM links as la, links as lb, cur as ca, cur as cb" to use
$links and $cur in includes/SpecialDisambiguations.php (otherwise the
page throws an error).
The third patch makes two changes to maintenance/tables.sql, following
the thread at http://mail.wikipedia.org/pipermail/mediawiki-l/2005-February/003367.html:
* A little change to the cl_sortkey index from the categorylinks table
so MediaWiki can be installed on MySQL 4.1 when utf-8 is the default
charset. Without the patch, the install script fails because the index
is longer than 1024 bytes.
* Forcing the log_title column from the logging table to be binary.
This is part of Brion Vibber's patch for bug 1057. I haven't tried the
rest of his patch because I modified the tables by hand, but at least
this part helps with new installations (though I agree that the rest
of his patch should also be included so people can upgrade; I'm just
not knowledgeable enough on PHP and MediaWiki).
--
/L/e/k/t/u
Hey,
due to lots of hackish code concerning reverse_timestamp, I'm going to nuke this column away. That'd provide some more compatibility with other DB engines and remove some overhead. This would remove performance optimization for old versions of MySQL 3.x and introduce filesorts there. Ooops.
Cheers,
Domas
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
MediaWiki 1.4rc1 is a security and bug fix release for the 1.4 beta
series.
== Important security updates ==
A security audit found and fixed a number of problems. Users of MediaWiki
1.3.10 and earlier should upgrade to 1.3.11; users of 1.4 beta releases
should upgrade to 1.4rc1.
=== Cross-site scripting vulnerability ===
XSS injection points can be used to hijack session and authentication
cookies as well as more serious attacks.
* Media: links output raw text into an attribute value, potentially
~ abusable for JavaScript injection. This has been corrected.
* Additional checks added to file upload to protect against MSIE and
~ Safari MIME-type autodetection bugs.
As of 1.3.10/1.4beta6, per-user customized CSS and JavaScript is disabled
by default as a general precaution. Sites which want this ability may set
$wgAllowUserCss and $wgAllowUserJs in LocalSettings.php.
=== Cross-site request forgery ===
An attacker could use JavaScript-submitted forms to perform various
restricted actions by tricking an authenticated user into visiting
a malicious web page. A fix for page editing in 1.3.10/1.4beta6 has
been expanded in this release to other forms and functions.
Authors of bot tools may need to update their code to include the
additional fields.
=== Directory traversal ===
An unchecked parameter in image deletion could allow an authenticated
administrator to delete arbitary files in directories writable by the
web server, and confirm existence of files not deletable.
== Changes since 1.4beta6 ==
* Fix notice error on nonexistent template in wikitext system message
* (bug 1469) add missing <ul> tags on Special:Log
* (bug 1470) remove extra <ul> tags from Danish log messages
* Fix notice on purge w/ squid mode off
* (bug 1477) hide details of SQL error messages by default
~ Set $wgShowSQLErrors = true for debugging.
* (bug 1430) Don't check for template data when editing page that
doesn't exist
* Recentchanges table purging fixed when using table prefix
* (bug 1431) Avoid redundant objectcache garbage collection
* (bug 1474) Switch to better-cached index for statistics page count
* Run Unicode normalization on all input fields
* Fix translation for allpagesformtext2 in LanguageZh_cn and LanguageZh_tw
* Block image revert without valid login
* (bug 1446) stub Bambara (bm) language file using French messages
* (bug 1432) Update Estonian localization
* (bug 1471) unclosed <p> tag in Danish messages
* convertLinks script fixes
* Corrections to template loop detection
* XHTML encoding fix for usernames containing & in Special:Emailuser
* (for zh) Search for variant links even when conversion is turned off,
~ to help prevent duplicate articles.
* Disallow ISO 8859-1 C1 characters and "no-break space" in user names
~ on Latin-1 wikis.
* Correct the name of the main page it LanguageIt
* Allow Special:Makesysop to work for usernames containing SQL special
~ characters.
* Fix annoying blue line in Safari on scaled-down images on description page
* Increase upload sanity checks
* Fix XSS bug in Media: links
* Add cross-site form submission protection to various actions
* Fix fatal error on some dubious page titles
* Stub threshold displays correctly again
Release notes:
http://sourceforge.net/project/shownotes.php?release_id=307068
Download:
http://prdownloads.sf.net/wikipedia/mediawiki-1.4rc1.tar.gz?download
Low-traffic release announcements mailing list:
http://mail.wikipedia.org/mailman/listinfo/mediawiki-announce
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.6 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCGYICwRnhpk1wk44RAp4SAJ9tUo4wzkeAwe7uJ3tQbKI2ZBYNXwCgyK1a
T6y4UfuG7ejvIOzyiOGq85Q=
=idOV
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
MediaWiki 1.3.11 is a security release.
== Important security updates ==
A security audit found and fixed a number of problems. Users of MediaWiki
1.3.10 and earlier should upgrade to 1.3.11; users of 1.4 beta releases
should upgrade to 1.4rc1.
=== Cross-site scripting vulnerability ===
XSS injection points can be used to hijack session and authentication
cookies as well as more serious attacks.
* Media: links output raw text into an attribute value, potentially
~ abusable for JavaScript injection. This has been corrected.
* Additional checks added to file upload to protect against MSIE and
~ Safari MIME-type autodetection bugs.
As of 1.3.10/1.4beta6, per-user customized CSS and JavaScript is disabled
by default as a general precaution. Sites which want this ability may set
$wgAllowUserCss and $wgAllowUserJs in LocalSettings.php.
=== Cross-site request forgery ===
An attacker could use JavaScript-submitted forms to perform various
restricted actions by tricking an authenticated user into visiting
a malicious web page. A fix for page editing in 1.3.10/1.4beta6 has
been expanded in this release to other forms and functions.
Authors of bot tools may need to update their code to include the
additional fields.
=== Directory traversal ===
An unchecked parameter in image deletion could allow an authenticated
administrator to delete arbitary files in directories writable by the
web server, and confirm existence of files not deletable.
Release notes:
http://sourceforge.net/project/shownotes.php?release_id=307067
Download:
http://prdownloads.sf.net/wikipedia/mediawiki-1.3.11.tar.gz?download
Low-traffic release announcements mailing list:
http://mail.wikipedia.org/mailman/listinfo/mediawiki-announce
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.6 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCGYHOwRnhpk1wk44RAhlzAKDSk3J8cRhBxD/arNc84uaLqeKAtgCfcJ2m
VRX58OZ0qf0b1dqhmfMFFe4=
=oYqv
-----END PGP SIGNATURE-----
Brion, help.
There are too many mails around - I cannot track them any longer.
May I propose to you: can't you set up wikis for mediawiki-l and
wikitech-l ***with e-mail notification*** ?
Newcomers could post their questions onto the wiki, developers could
answer, and whole message threads including solutions and patches would
stay together and would be better to maintain.
Of course, an installation with a working e-mail notification would
support the communication with much lower mail transfer (remember, only
_one_ e-mail is sent out for a watched page, until the watching user
re-visits the watched page - can be weeks later).
Perhaps: the both wikis only writeable for users who have registered
with one of the mailing lists
I propose my current en201+mw1.3.10 from
http://meta.wikipedia.org/Enotif to be installed on something like
wikitech.wikipedia.org or even
Or be courageous and start trying it on meta.wikimedia.org .
Good or bad idea ?
Tom
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
A few minutes ago, (German) wikipedia was really fast and responsive.
All of a sudden, it is down to the usual sluggishness, maybe even worse
than usual. The change between these two states was rather sudden and
quite big.
Did anyone plug in a new server or something? Or was it just my local net?
Just curious,
Magnus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCGN4nCZKBJbEFcz0RAv4zAJ4i+QCdXtV94BdwaOpGjq4BcC8mfgCeNR9E
KqjU+y4jP/SXoiXhiAsFkWo=
=qufp
-----END PGP SIGNATURE-----
Hi,
We at the Kurdish Wikipedia/Wiktionary have the (maybe unique) problem,
that Kurdish is not only written with two different alphabets (latin and
arabic-based), but that these two scripts are written in different
directions. I am looking for technical support here before I post
anything as a feature request to the bugtracker.
While the majority of all articles is (and probably will be) left to
right, often both directions are needed on one page, while some can be
entirely right-to-left. Until now, noone has proposed to split the
Wikipedia, on the contrary we want to include both scripts and provide
optimal usability for both. Following are some problems for the
right-to-left support:
*Page titles are partially incorrectly displayed, because all browsers
interpret left-to-right words different that left-to-right paragraphs
*Lists appear incorrectly. Example:
http://ku.wikipedia.org/wiki/%D9%88%D9%87%E2%80%8C%D8%B4%D8%A7%D9%86%DB%8E%…
*Font problems.
The main problem seems to be that it is not possible to define a whole
page as right-to-left. After a lot of trying we found a patial solution.
Pages that are RTL use a template with a <div>-tag with a .rtl-class.
This works, but it is a suboptimal solution, especially because a
newcomer who wants to write RTL faces problems.
A solution would be something that defines whole pages as RTL, optimal
would be a connection with the pagename: when the pagetitle is in arabic
script, the page content should be RTL.
I would be glad about any help on the issue.
Greetings,
Erdal