brion vibber (brion @ pobox.com) wrote:
> Binary attachments are stripped from the
> list to help keep virus mails off. Best
> to open a bug report on bugzilla.wikipedia.org
> and post your patches there...
Done. See it here:
http://bugzilla.wikipedia.org/show_bug.cgi?id=234
I hope it works!
Eric
=====
Do you know stuff? Contribute to Wikipedia! http://www.wikipedia.org/
Help preserve the public domain by becoming a Distributed Proofreader. http://www.pgdp.net/
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Hello again.
I just had a descussion with JeLuF on #mediawiki about the concept of
categories. Here is a summary of the main points that came up (but where
not neccessarily agreed upon):
* Categories as they are have prooven rather useless and confusing (at
least in the german WP). Cross-Sections and transitive covers have been
agreed there to be the core features missing to create a functioning
structure of categories.
* Nikola Smolenski proposed a patch for linking to cross-sections of
categories using a syntax like [[:Category:Woman/German/Author]] to get
female german authors. That syntax would break some existing categories,
but changing the syntax is not a problem. The patch was discussed here
and dismissed as not practical (why exactly?).
* Cross-Sections of categories are only useful if we also have a
seach-page that allows for that feature. Possibly, this is even more
important than linking to cross-sections.
* Cross-Sections of categories are only useful if we can search over the
transitive closures (members of all subcategories, recursively). An
alternative would be to dispose of subcategories all together - but that
would require extensive redundant categorisation of articles.
* Besides linking to cross-sections, it would be useful and intuitive to
allow an article to be added directly to a cross-section. That is,
[[Category:Woman/German/Soccer player]] should put the articles into
[[Category:Woman]], [[Category:German]] and [[Category:Soccer player]].
* One problems with transitive closures are circularities in the
sub-category relation. As I can't think of any situation where such a
circularity would make sense, I think they sould be avoided alltogether.
Maybe the software could output an error when it is attempted to
create a circular dependency?
* Another way of avoiding circular dependencies and non-intutitive
results of transitive closures would be to allow categories to *belong*
to other categories, without being a *subcategorie*. IMHO subcategories
should be declared using a special syntax, like [[Supercategory:Foobar]].
* Another problem with transitive closures is efficiency: storing graphs
in a relational database is not trivial and generally ineficient. I
think it would be best to store all "implicite" memberships of an
article whenever the articles assignment to categories changes. But that
would mean that a *lot* of article-entries have to be updated when a
subcategory-relation is added or removed. I belive this point to be the
main issue with my proposal for advancing the concept of categories.
* The concept that is actually wanted (in the de:WP) is general
metadata, consiting (at least) of the dimensions Time, Space, Type (of
objet or article), Topic (field of study), and Keyword (loose
bibliographical collections). Using this dimensions together with
cross-sections and transitive closures would yield a truely powerful
structure. The existing concept of categories should be expanded to meet
those requirement - the distinction of the dimensions, however, do not
need to be hard coded. Naming-conventions would be sufficient.
Could you please give me your opinion about these points? I would be
especially interrested in knowing if anyone has a good ideas as to how
to implement transitive closures efficiently. I belive that to be the
core problem here... and it would be *extremely* helpful to have that
feature. If someone can give me a definite "forget about it" with a good
reason, I would be disappointed, but it would be OK too...
Thank you very much
Daniel
I've been beating my head against the problem of
getting transparent and non-transparent PNG thumbnails
to be the same color depth as the source image, to
resolve a couple issues:
* Thumbnails of palette (8-bit) PNG images are
currently truecolor, meaning the thumbnail is often
close to the same size (in bytes) as the full-size
image. The thumbnail should be the same color depth as
the source.
* PNGs with transparency, as a consequence, have
varying degrees of transparency (rather than simply
transparent/opaque), wreaking havoc with Internet
Explorer, which does not support them.
There is currently some discussion on the Village Pump
about my attempts at fixing these problems, by editing
includes/Image.php where the thumbnailing function
resides. I do not know for sure whether the GD
libraries or ImageMagick are currently in use in the
live version (ImageMagick was default on my
installation, and from what I can tell that's what's
used on the WP site). Because of the constraints of
both ImageMagick (can't create palette images from
truecolor) and the GD libs (a number of minor
annoyances that add up to major problems), I was
wondering whether it'd be okay to use a combination of
the two. My very first attempt at putting them both
together resulted in exactly what I was looking for.
ImageMagick resizes the image (preserving any
transparency), and the GD libs convert to palette.
Since I do not yet have CVS access, I am attaching a
diff against the 1.19 revision of includes/Image.php.
Again, I don't know if it's appropriate to use
ImageMagick and GD together, but it may solve a
problem that has been bothering quite a few people.
Eric
=====
Do you know stuff? Contribute to Wikipedia! http://www.wikipedia.org/
Help preserve the public domain by becoming a Distributed Proofreader. http://www.pgdp.net/
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush
I need more variables than the current ones (see
http://meta.wikimedia.org/wiki/Help:Variable )
especially needed are:
{{{PAGEEDITOR}}}
{{{PAGEEDITTIMESTAMPUTC}}}
{{{PAGEEDITOREMAILADDR}}}
{{{PAGEEDITTIMELOCALTIMEOFEDITOR}}}
to be used in templates.
Imagine a Personal View Disclaimer template called Template:PVD . It can
be referenced on any page as {{PVD}} .
But this template shall end up with the current NAME OF THE PAGE EDITOR
who used this template on a page Z !
<div id="toc" style="background:#F2F8F8;border-width:1px 1px 1px
1px;">''[[PersonalViewDisclaimer|Personal View Disclaimer]]:''
The content of this page represents my personal opinions. It does not
represent the view of my employer, or any one else, for that matter, in
any way. My thoughts and opinions may change over time. Old entries do
not necessarily reflect my current thinking. {{{PAGEEDITOR}}}</div>
I hope, that you understand, what I mean. I could not find a solution to
solve my problem. Reading the source of 1.3.1 and
http://meta.wikimedia.org/wiki/Help:Variable I guess, the patch is not
that difficult, and the above mentioned variables can easily be
retrieved from the database tables and are an amelioration of MediaWiki.
Tom
Could somebody please look at the situation of images on Wikisource.
All of them give 404 errors, and "What links here" invariably shows
that nothing links to them.
Ec.
PS. This was mentioned on the Bug reports there on August 11. I then
let it sit to see if anything would happen; nothing did. There's no
blame attached, because I can appreciate that there are just too many
projects to patrol for bugs. Would it be possible to have the bug
report pages all redirect to a series of pages on the same project so
that they could be patrolled more easily? Each of these pages could be
named in such a way as to identify which project is experiencing a bug..
Ec
[I sent this yesterday, but it seems to have gotten lost somewhere.
Apologies if it ends up arriving twice.]
Morning,
Raul654 and I were having a discussion earlier about sending a daily
featured article via email, similar to "word of the day" at m-w.com
etc.
The easiest way to do this would be via a mailing list which users
subscribe to; however, mailman's interface isn't really very obvious
for someone who's just looking to sign up for something. So, it would
be nice if something could be added which would handle the initial part
of the subscription when the user enters their email address into a
(simple) form, and they just have to reply to the mailman email to
subscribe.
Is there any chance of something like this being done, or does anyone
have any other suggestions on how to handle it?
Kate.
Dear All,
Since switching de.wikipedia to UTF-8 a problem with image uploads
from Mac OS X surfaced. The Mac OS X filesystem, IMHO contrary to
most other ones, stores the filenames in decomposed Unicode.
As an example look at a file named "ü" (small u-umlaut):
Normal use is the Unicode codepoint:
U+00FC LATIN SMALL LETTER U WITH DIAERESIS
This is
0xC3 0xBC in UTF-8
"%C3%BC" as URL
Mac OS X use is this Unicode copdepoint sequence:
U+0075 LATIN SMALL LETTER U
U+0308 COMBINING DIAERESIS
0x75 0xCC 0x88 in UTF-8
"u%CC%88" as URL
Now uploading images from a Mac will give them the unusual
filenames, which cannot be spotted by sight in most cases.
Using the images will fail, if you simply type image name
as you see it. Copy'n'paste the "Mac" umlaut filename will
work but will make everything even less transparent.
Example image:
http://de.wikipedia.org/wiki/Bild:To%CC%88o%CC%88a%CC%88a%CC%88st.jpg
German discussion Page:
de:Wikipedia_Diskussion:UTF8-Probleme#Umlaute_in_Upload_Dateinamen_bei_Mac_OS_X
The most foolproof solutions seems to me, to normalize incoming
filenames to NFC (composed) form by the server software.
Regards,
Peter Jacobi
The following was sent to me by Nikola Smolenski (thank you very much!).
I'm forwarding it to this list hopeing that someone can suggest the
proper way to get this into the CVS.
thanks, daniel.
-------- Original Message --------
Subject: Re: [Wikitech-l] Advancing the concept of categories
Date: Wed, 25 Aug 2004 11:08:50 +0200
From: Nikola Smolenski <smolensk(a)eunet.yu>
To: Daniel Kinzler <daniel(a)brightbyte.de>
References: <20040824053338.75B8519503A4(a)mail.wikimedia.org>
<412B7282.30307(a)brightbyte.de>
Hi David!
On Tuesday 24 August 2004 18:53, Daniel Kinzler wrote:
> In the german WP, we have massive problems devising a consistent and
> useful pattern for categorisation. After some trying and discussiong, it
> seems that the software laks some features that would make categories a
> truly powerful tool of structuring the WP. So my question is how hard it
> would be to implement those features. Here are the once I personally
> (and quite a few others, too) feel are the most important:
>
> * Search over cross-sections of categories, an a sensible syntax for
> linking to such sections.
I have made a patch which does this, and Timwi did some improvement on
it, but
it is not commited for reasons unknown to me. See "Multiple categories"
thread at
http://mail.wikipedia.org/pipermail/wikitech-l/2004-July/thread.html
The patch makes cross-sections by separating categories with / , for
example
Category:City/Germany gives a list of all cities in Germany. Someone
reported
that there are several (about 10 on all Wikipedias) categories which have /
in the name so perhaps there should be a vote on Meta about this (should
these categories be renamed or should some other separator be used and
which
one; Timwi suggested // ).
I really don't know how to convince someone with CVS access to commit this
patch. Perhaps a feature request should be made at wikizilla and voted for.
> * a concept of implicite membership in categories, such that members of
> a sub-categorie are automatically members of the parent-categorie(s)
> (transitive covers). For category-display, this should be optional. For
> cross sections, this should be the default behaviour.
>
> * A disctinction between a categorie being a subcategory, or just
> belonging to another categorie, just as Articles do.
>
> would it be feasable to put this features into the software? What would
> be the problems? how soom could we have such features?
It could probably be done, and I could do it, but I surely won't before the
first one is implemented.
The link placeholders are causing lots of problems in 1.4: links that do
not appear in the body text end up with the placeholder comments but are
never replaced with the actual links.
For example, the user name in the subtitle for Special:Contributions.
This may be behind http://bugzilla.wikipedia.org/206 also.
This is kind of a problem. Do we need a way to turn the placeholdering
on and off, or should we have distinct makeLink* functions for making
placeholder links?
-- brion vibber (brion @ pobox.com)
Been meaning to do this for ages... I've just checked in a replacement
for the old wiki page-based LogPage system which uses an actual table,
and Special:Log as a viewer.
Why do wiki-based log pages suck? Let me count the ways:
* Timestamps can't be shown in the user's local timezone and format.
* Links in the log can break assumptions (image use, wantedpages, etc)
* Broken or long markup in comments often breaks the logs beyond legibility
* They get *really long* really quick on big wikis like en.wikipedia.org
* Archiving them manually is a pain in the butt and makes it hard to
look up past information
* The way it overwrites the current revision breaks history/contribs so
they don't behave like normal pages anyway.
* When someone changes the translation for the log name the log breaks
continuity.
Why does a log table rock?
* Like page history, only shows the most recent N items but can dig
arbitrarily far backwards
* Won't break when someone 'archives' or renames the page.
* Can limit the display to actions by a particular user
* Can limit the display to actions on a particular page
* Can limit the display to actions in a particular date range
* Can combine all logged actions in a single display, or keep them separate
* Links don't stink up the link tables!
* Comments don't get fouled up with unintended markup.
* Timestamps use user's timezone and format preference.
I had to modify the recentchanges table to allow signed namespaces in
order to include Special:Log updates in RC. Right now they list kind of
ugly, as eg 'Special:Log/delete' but RC could be hacked to display a
localized name as a special format (as we have a special format for page
moves). Be sure to run patch-logging.sql to update the tables.
There are probably still some rough spots: please try out all the
loggable things and make sure the result is more or less pleasant.
Messages probably need updating to look nicer or point at the new log
location.
-- brion vibber (brion @ pobox.com)
