Salut à tous,
Toute personne souhaitant pouvoir assister à l'AG et élire les membres
du conseil d'administration doivent impérativement être à jour de leur
cotisation 15 jours avant l'AG. Ce qui doit fait : 27-15=12... bref
bientôt.
Tous les détails pour cette formalité se trouvent ici :
http://www.wikimedia.fr/wiki/Devenir_membre
À partir de cette année les adhésions se feront pour une année civile,
soit 2007.
Nous avons enregistré un nombre faible de candidatures au conseil
d'administration. Un délai supplémentaire a donc été accordé jusqu'a
demain soir. Afin de garantir une élection juste et un bon
fonctionnement de l'association, nous appellons donc toutes les bonnes
volontés à poser leur candidature.
Vous trouverez bientôt ces candidatures en ligne.
Toutes les informations concernant l'AG se trouvent ici :
http://www.wikimedia.fr/index.php/Assembl%C3%A9e_g%C3%A9n%C3%A9rale_du_27_j…
Emmanuel Engelhart
I have identified an organization which is willing to spend up to
about EUR 10,000 on adding support for exporting MediaWiki pages as
PDF files, and improving document management for documents consisting
of multiple pages.
My current thinking is that the functionality implemented, as a
minimum, would be as follows:
a) Using an extension, integrate of a "PDF link" on any wiki page
which would call an external library like HTMLDOC on a single wiki
page
b) Support filters on the rendered HTML (replacing image thumbnails
with high resolution images, filter content by regular expression,
etc.), and revision filters (export last revision edited by user on
whitelist Y, or approximating currentdate-Z)
c) Create a "PDF basket" UI which makes it possible to compile a PDF
from multiple pages easily (and rearrange the pages in a hierarchy).
The resulting structures could potentially also be stored as wikitext,
using a new <structure> extension tag, so that they can be used both
by individuals compiling PDFs for personal use, and by groups
collaborating on complex documents.
Possibly some budget could also be allocated for improving the
external PDF library used, especially if we can allocate additional
funds for this project.
I'd like to request comments on this approach, specifically:
- Besides HTMLDOC, do you know a good (X)HTML-to-PDF library which
could be used for this purpose?
- Within this budget, do you believe an alternative approach which
utilizes an intermediate format is viable (e.g.
wiki-to-Docbook-to-PDF), given the complexity of the MediaWiki syntax,
its various extensions, and the need to keep up with parser changes?
- If you are a developer, would you be interested in working on this
project, and available to do so? (If so, please contact me privately.)
Any other comments would also be appreciated.
--
Peace & Love,
Erik
DISCLAIMER: This message does not represent an official position of
the Wikimedia Foundation or its Board of Trustees.
Hello,
Currently, wikipedia's categories seems to be a flat categories system
- no fixed common categories naming & inter relationship,
let me give an exampe,
consider you have to implement a function, on the wikipedia's data
// returns all places name (direct or indirect) under the place
Place[] function getAllPlaceName(Place) {
}
The expetced outcome would be,
['Manhattan', 'Brooklyn', ....] = getAllPlaceName("New_York_City");
['Manhattan', 'Brooklyn', 'New_York_City', 'New_Jersey', ....] =
getAllPlaceName("USA");
how would you implement the function?
hints: this should also work with other countries & languages.
after spending a few hours, my outcome is that is it not possible for
a truely automated solution!
Wikipedia Categories have no semantic relationship...
Aerik,
Very interesting, but what puzzling results. I tried intersections of some
of the largest categories I could think of and got wildly different
results. The first time I tried American actors intersected with Living
people the results took 1.5 seconds the next time I tried it it was 0.0011
seconds. What does this mean? Is the long result because of server
traffic? Is the short result close to the time that it actually took? Are
the results being cached? Also, the intersection of large categories with
numerous articles common to both seems to take longer than categories of
similar size with no common articles. This is not what I expected. If you
are just looking for the first 30 results, I'd expect the first case to be
faster. The second has to look through the entire category for a match.
My question to developers is what is the criteria for an acceptable
solution? How much time can an intersection be allowed to take? How often
do we think people will be looking for intersections? Can we save the
results of a popular intersections (like American people intersected with
Actors) so that the intersection is updated less frequently?
User:Rick Block, User:Radiant! and I have been discussing ways to optimize
or limit intersections so that server load will be less of a problem and
hopefully doable. Please see our discussions at [[en:User
talk:Radiant!]] Also, if anyone hasn't seen it, we've done quite a bit of
work on possible user interfaces. These are at [[en:Wikikpedia:Category
intersection]].
There are many ways intersections can be constrained to put less of a load
on the servers. I'm hoping that we can implement this at some level
soon. The categorization system is being turned into a database search
system. Instead of having broad rich indexes for each category, everything
is being chopped into tiny bits. Look at [[:Category:Battles of the
American Civil War]] for an example of this. The battles have been broken
into so many tiny pieces that there is no way to browse through all of
them. It is becoming harder to browse through many topics and
over-categorization is increasing. Implementing category intersection will
mean that users will be able to browse through categories at whatever level
of specificity they desire. The longer we wait for this to be implemented,
the more broken up categories will become (at least on en: German Wikipedia
doesn't seem to have this problem).
Thanks, and keep up the great work.
Samuel Wantman
[[en:User:SamuelWantman]]
Sorry if this is a really easy question, but how can sysops add new accounts to MediaWiki if public creation of accounts is disabled? Is there some hidden link, or extension available? I don't see anythign relevant under Special Pages.
--
_______________________________________________
Search for products and services at:
http://search.mail.com
Powered by Outblaze
[For the record, this was a response to
http://bugzilla.wikimedia.org/show_bug.cgi?id=1085 ]
[Civility:]
Rob Church <robchur@...> writes:
> We might not implement their letter, but the spirit of the ideas of
> keeping civil and assuming good faith *are* applied at the development
> level; we just reserve the right to be blunt.
Being blunt or dismissive is completely contrary to the letter and spirit of
WP:CIV. Things like:
* Rudeness
* Judgmental tone
* Belittling contributors because of their skills
* Personally targeted behavior that causes an atmosphere of greater
conflict and
stress
"Bluntness", if that's what we're calling it now, only makes things worse, and I
see it a lot when developers are involved.
I would very much like to see some guidelines for interpersonal behavior in the
development process. As far as community and wikilove are concerned,
development of the site's software shouldn't be any different from development
of the site. No one should get a special exemption to be an asshole to other
Wikipedians just because they know PHP.
> If we're to implement certain tweaks for this in user preferences,
> then we need some co-operation from the user base to allow us time
Shouldn't that have been implemented *before* going live with this feature?
> There's always the
> Subversion log. Oh, but of course...non developers don't apparently
> like opening their damn browsers.
What's a Subversion log?
> That attitude could very well lose you a lot of the behind-the-scenes
> supporting cast one day, without whom you wouldn't even *have* a
> website.
Oh please. The exact same thing could be said about the site's users. Without
content contributors, there would be no point in even *having* a
website, etc. etc.
Disputes like this could drive *both* developers and editors away, and we need
both (though in practice, it doesn't drive anyone away; it just causes them
undue stress and impedes progress).
We're all volunteers, here. We're all contributing our free time to the same
altruistic project without getting anything in return except appreciation. Some
of us know how to code websites, some of us know about Japanese fighter planes,
some of us know how to write CSS, some of use know about rodent biology. More
love and understanding and less arrogance, elitism, and belligerence, please.
The problem here is that visible changes to the site's functionality can be made
in a few different ways (Mediawiki itself, site javascript, site CSS, template
markup), and when there is such a change, it's not discoverable at all how that
change was made or who was responsible for it. It's not visible except to the
few people who happen to be watching that template, or watching that CSS page,
or know how to access and understand Mediawiki's CVS or whatever it is. There's
no centralized place on the site where new features are announced ("You'll be
noticing a new addition to the watchlists starting today; it tells you this and
that and does this and that"). There's no centralized discussion point where
people can present their ideas for features and have those features critiqued by
the people who are actually going to use them. There's no test site where
features are auditioned before going live. Things just go live randomly, in
ways that may or may not be optimal for the site, and no one even knows where to
complain.
[Now, onto the actual feature being discussed:]
Gurch <matthew.britton@...> writes:
> Exactly. I very much doubt anyone wants their diffs to look like mine
> (the stuff that's usually grey isn't even visible, they're blue and
> yellow, and generally ugly as sin). I also doubt many people want the
> "Go" and "Search" buttons hidden, as I have done (I just press Enter to
> Go, and my browser has a search box). But that's the way *I* want
> things, and because the interface can be customized that way I can have
> it that way.
That's fine. But these numbers are similar to those changes. Only a few people
want or use them, but they're on by default. Like implementing your "ugly as
sin" diffs for the entire site by default, and then telling people they need to
change their user CSS to remove them. It should be the other way around.
Something like this should be a user preference. "Edit your user CSS" is NOT a
user interface. Wikipedia editors are supposed to be regular people; not
hackers. The site is supposed to be easy to edit, to avoid systemic bias, but
it just gets more and more technical and more difficult to use all the time.
Easy-to-use wiki markup has been abandoned in favor of HTML-esque tags for
everything, article source code is cluttered with ref tags and table markup and
on and on. (I don't think refs or tables are bad, of course; I just think they
were not fully thought through, and implemented in a rush without much feedback
from the non-hackers who have to use them. There are better solutions out there
in the proposals bins that have just been ignored.)
I don't even see what these numbers are useful for. Maybe if someone lies in an
edit summary and says "small change" while the numbers say "big change", but
that's about it. It doesn't give me any useful information about the diff
except in that case. They don't actually tell how big the edit is, as some
have said; they just tell how much the page has changed in size. That's a
pretty meaningless metric. It may even be harmful; giving a false sense of
security for low numbers. Changing
"He was elected the" into
"I like to eat poop", for instance, tells the patroller that nothing significant
has been changed:
12:31 User:Omegatron/George W Bush (diff; hist) . . (0) . .
Omegatron (Talk | contribs | block)
These numbers don't tell me what the edit actually was; I still have to visit
the diff as I normally would. They don't even tell me which edits to
preferentially focus on for fighting vandalism. I behave exactly the same when
viewing my watchlist with or without these numbers. I don't see how they help
anything or save time anywhere. And no, I'm not a lone whiner:
http://en.wikipedia.org/wiki/Wikipedia_talk:Added_or_removed_characters#To_…
A much, much more useful solution would be to expand the automatic edit summary
feature for all edits, as has been suggested several times for a few years. We
finally got a limited auto edit summary feature recently
(http://en.wikipedia.org/wiki/Wikipedia:Automatic_edit_summaries), which is
great and really helpful, but it should be expanded to cover all types of diffs
and then shown on *every* edit, regardless of whether the user fills out an edit
summary or not. The edit summary field would be used for a prose summary of
what was edited and the rationale for the edit, but the automatic summary would
tell explicitly *what* was edited, and, in a lot of cases, completely prevent
the need to view diffs to see whether the edits were valid or not, saving
bandwidth and money for the servers and saving time for editors. Vandalism
would be immediately visible on watchlists or recent changes.
http://en.wikipedia.org/wiki/Wikipedia_talk:Automatic_edit_summaries#How_to…http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28perennial_proposals%…http://bugzilla.wikimedia.org/show_bug.cgi?id=1307
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Just a little note; I've been going through fixing line ending styles on
a bunch of files and thought I'd remind you all of the issue. :)
As you probably know, DOS/Windows and Unix/Linux traditionally use
different control character sequences for line endings: Windows uses a
CR followed by LF (\r\n) while Unix uses LF alone (\n).
This can lead to annoyance when people edit each others' files; the
files can end up mixed or incorrect or otherwise very WTF-ish.
In particular the Semantic MediaWiki and Wikidata extension files had a
lot of unmarked DOS files and broken mixed-style files, which I've
cleaned up, but there were others in core and other extensions.
Subversion can do automatic conversion of line endings on
checkin/checkout, like CVS, but unlike CVS this isn't the default on new
files you check in unless you've configured it.
To help keep the line endings straight, I strongly recommend setting up
your Subversion 'auto-props' settings to set the svn:eol-style property
on new text and source files:
http://www.mediawiki.org/wiki/Subversion/auto-props
Please note that this isn't just for Windows users; _all_ committers
should ensure that their files are properly marked when they check them
in, or some other schmuck may mess them up when editing it later.
- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFnb/rwRnhpk1wk44RAj3wAJ4wXrpX7f5oQMIT4az8Q6D4sga+wgCgslqh
GlUZwtjX+Ax/arI8T1I8YPY=
=Bc+6
-----END PGP SIGNATURE-----
Hello!
You are receiving this email because your project has been select 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 relation 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 second release candidate of PHP 5.2.1 was released today, it can
be downloaded from http://downloads.php.net/ilia/. Since RC1 there
have been mostly bug fixes and I do believe any new regressions or
bugs were introduced. If you discover any (we hope not) please notify
PHP's QA team at "php-qa(a)lists.php.net".
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