Hey everyone,
I'm Dave and I work for Wikia. I've been a lurker on this list, but
this is my first post and extension release, so go easy on me :P
I just wanted to let everyone know that we've bundled up some of our
social features for Open Source, including basic profile information,
friending, and "wall" messaging". It's been tested and runnning on
sites using MW 1.10. More information can be found on the extension
page http://www.mediawiki.org/wiki/Extension:SocialProfile.
If you want to see some of the features in action, check out:
http://www.armchairgm.com/User:Romiezzohttp://halo.wikia.com/wiki/User:ED
If anyone has any questions, suggestions, or issues, please let me know.
I'm looking forward to being apart of this great community!
Thanks!
David Pean
Hi everyone,
I'm developing an extension and I need to override the behavior of a method
from the Linker class. More precisely, I need to override 'makeImageLink2' to
create custom links for certain images. I searched for a related hook but I
could not find anything. Can this be done from an extension?
Thanks in advance,
--
Yasser González Fernández
http://deltha.uh.cu/~yglez/
Neil Harris wrote:
>
> Magnus Manske wrote:
> > I just found
> >
> >
> http://point.davidglasser.net/wp-content/uploads/point.davidglasser.net/200…
> >
> > and thought I'd share it with the list...
> >
> > Magnus
> >
>
> Interesting. What they seem to be proposing is to store the tags for
> each article in a plain text field, and then use the built-in MySQL
> full-text search mechanism to index and search that, thus taking
> advantage of all the development already devoted to speeding up
> general-purpose full text search.
>
> I wonder how it would scale to Wikipedia's vast datasets?
>
>
Argh... I tested exactly that question last year:
https://lists.wikimedia.org/mailman/htdig/wikitech-l/2006-December/028081.h…
and then talked about it again here
https://lists.wikimedia.org/mailman/htdig/wikitech-l/2008-February/036570.h…
I think that the fulltext solution is probably very good for a mid-size
application, but it sounds like (form people who know more about MySQL
databases than I) that it would not stand up to Wikipedia's traffic. Tim
Starling suggested that Lucene is better at intersections that MySQL's
fulltext database... I also did some testing with a lucene index, but I
really don't want to set up Java on my server to I used Zend_Search_Lucene.
That gave performance similar to the MySQL fulltext index *BUT* when I
queried the same index with Luke (which is Java), the query was *fast*.
Sorry, I can't find the mailing list posts about that.
So, I think the solution is to either a) add a field to the current search
index or b) create a new search index. A fulltext index might make a nice
addition to mediawiki for smaller installations though (and folks who don't
want to run java).
FYI, I am using a fulltext index for tagging on my social bookmarking
application http://tagthis.info (I know it's not a great social bookmarking
app, the idea is that it's a hosted service where anyone can add tags to
webpages with some javascript - I'm beta testing it on my wiki directory)
and at that scale the performance is very adequate. I'm looking at clucene
to set up an indexing daemon for the my higher performance searching needs
(maybe might interest folks on this list?)
Best Regards,
Aerik
--
http://www.wikidweb.com - the Wiki Directory of the Web
http://tagthis.info - Hosted Tagging for your website!
Hi,
I have a large volume of valid xhtml [xhtml1-transitional.dtd] that I want
to import into my MediaWiki instance.
Are any good filters available that might convert my xhtml to MediaWiki's
wiki-text format?
Thanks,
~mm
Hi guys.
I run the "wikipedia for schools" static version and am looking at size/
download possibilities for the 2008 version. Clearly we will keep offering
this for free but I wonder if anyone has a better "how to" solution.
The 2007 thumbnails version is 700 Mb and even 8 months after launch people
are still taking 500Gb a month bandwidth on downloads. The larger version (
2.3Gb) was on Torrent but that seems to be broken so we are mailing out DVDs
at a high rate too.
Current list of rated articles is nearing 30,000 ( 8x last year) so either
we have to think about a very different product (won't run direct from a DVD
file, multiple disks) or we have to select much more on relevance as well as
just taking acceptable quality. Probably we will go for a size where
thumbnails or mid image size version still goes on a DVD, where we have
8-10,000 articles and where we have a larger version at 5Gb or so for some
sort of compressed download. However, when we put a newer larger version up
we are worried about just how big the bandwidth might be. Also whether to
re-try Torrent, whether there is something better and whether to use a
remote download service like Amazon.
SO: you guys must have some really big downloads and bandwidths to handle
and understand them much better than I do. What should we go for to provide
this free service to offline static users at a minimum price?
BozMo
With the advent of __HIDDENCAT__, I've been wondering about using
hidden categories to create indexes. My initial hope with Wikipedia was
that we could reorganize categories so that categories could function as
broad indexes of single attributes such as "People", "Films", "Bridges",
etc... and hide all the intersection categories of parents. Later, if
and when category intersection was implemented, all the hidden
categories would no longer be needed. However, implementing major
changes seems to be near impossible in a project as large and set in its
ways as Wikipedia. There is just too much resistance to change. If
category intersection was implemented there would be an technical
compelling reason to make the change, but short of that upgrade, it
seems like a very difficult -- if not impossible -- sell.
It really bothers me (and others, especially librarians), that Wikipedia
is not indexed. You cannot find a master index of People, places,
books, films, etc... To find anything you have to know in advance,
where it is subcategorized. This only works if you know where to
browse, and it is your desire to only browse in a small well-defined
place. One of the big joys of libraries is the ability of finding
things you didn't know about in broad swaths of knowledge. This ability
is often lacking in Wikipedia because of categories being constantly
broken into smaller pieces. For example, If I want to browse through
the bridges in Europe, I have to look at a category for each country
separately, and in some countries (like the UK) I have look at one for
each county. It is just too difficult and time consuming a task to be a
pleasurable leisurely browse.
So I've been thinking of alternative approaches. One possibility is to
use hidden categories to create index categories. For instance,
[[Category:Index-Films]] could contain all films,
[[Category:Index-People]] could contain all people, etc... However,
this would be difficult to maintain because the categories would be
hidden, and it would take a tremendous amount of work to populate these
categories. It seems crazy to have people doing all the mindless
busywork necessary to create categories like these. That is why we have
computers.
This is where developers come in...
I'm wondering about creating a new namespace, called (you guessed it)
INDEX. Any category of people could be put in an index by adding
[[Index:People]] on the category page. The "People" INDEX page, into
which the category get put, would have links to all the articles and
subcategories from the categories in the INDEX. The contents of the
subcategories of those categories would NOT be added automatically.
Each would have to be manually added to the index if appropriate. Just
like a category there would be text that could be edited for each INDEX
page. So in essence, an INDEX is a way to do category unions. This
would be much, much easier than trying to create and maintain these
indexes manually using categories.
It would be great if an INDEX page could be viewed two different ways
(and easily switched). The first way would look similar to current
categories, showing a category tree at the top, and all the articles
below arranged alphabetically. It would also be great to see categories
viewed hierarchically, like an index in a book. So the categories would
be listed alphabetically and then all the subcategories and articles in
the categories would be listed together alphabetically and indented.
The categories could be differentiated by either making them bold,
italic, or by labeling them as categories. If the subcategories have
also been included in the index, their contents would also appear
indented in one more level (this could be closed at first and opened
using a "+, the same way category trees look. Users might also be able
to set the default number of levels that appear -- perhaps two?).
I don't think there is any need to be able to add anything but
categories to an INDEX. Adding anything else would probably make it
harder to maintain the INDEX, and would probably confuse newbies. Of
course, you should be able to create a link to an index page by typing
[[:Index:People|Index of people]].
If you think this idea has merit and is a possibility, would it be
difficult to implement? It has long been my understanding that category
unions would be much less server intensive than category intersections.
Perhaps each INDEX display process could be done dynamically?
Thanks,
Samuel Wantman
[[en:User:Sam]]
Does anyone know how well this extension works? Has anyone used it?
It claims to be able to restrict access to all pages except those on a
whitelist, FOR EACH INDIVIDUAL USER. The last part there, of course, being
the bit that makes me suspicious. The documentation on Meta mentions no
holes, workarounds, or flaws of any kind. Does this extension do what it
says on the tin?
Hi,
I am writing to request an SVN account to host source code for an extension
that we are currently developing for MediaWiki. This
extension is being developed by a collaboration of two Northeastern
University students and CIM Engineering, Inc (dba
"CIM3").
The Software Idea:
With 2,073,813 articles in English and growing, Wikipedia is the
world's largest collaboratively edited source of encyclopedic
knowledge. As more and more people adding content and using it as
reference for their research, it becomes important to know what
data resides where on the wiki. Users generally do this by book
marking page for future reference. Book marking option in web
browser let you bookmark the URL, which is generally the whole
page. With the amount of content on any given page, it might
still take a while to find the content user is looking for. The aim of
the projects is to produce an extension that will add Purple
Numbers and collaborative tagging capability to MediaWiki. Purple
Numbers will provide the following added functionality in
MediaWiki.
1.* High resolution addressability in a wiki page:*
With Purple Numbers, MediaWiki user can have high resolution
addressibility to a wiki page. The purpose of Purple Numbers is
simple: to produce HTML documents that can be addressed with high
resolution (also called "fine granularity"). It does this by
automatically creating name anchors with static (nidÿÿs) and
hierarchical (hidÿÿs) addresses at the beginning of each node,
and by displaying these addresses as links at the end of each
node.
2.* Transclusion:*
Transclusion is the inclusion of part of a document into another
document by reference. Transclusion is best explained by an
example. Consider the following scenario a user wants to display
some data (picture, chart, etc.) about X on page that mentions X
in some other content. With Transclusion, user can reference data
about X from the X page without copy/paste the data on their own
page. Since the data is referenced and not copied, any changees
made to the data will reflect on the userÿÿs page also.
3.* Collaborative tagging at node (Purple Numbers) level:*
Collaborative tagging (also know as folksonomy, social
classification, social indexing and other names) is the practice
and method of collaboratively creating and managing tags to
annotate and categorize content. In contrast to traditional
subject indexing, metadata is not only generated by experts but
also by creators and consumers of the content. Freely chosen
keywords are used instead of controlled vocabulary.
Some Important Links:
Project Wiki:
http://project.cim3.net/wikihttp://project.cim3.net/wiki/PMWX
Project Status:
http://project.cim3.net/wiki/PMWX
History of Purple Numbers:
http://community.cim3.net/cgi-bin/wiki.pl?PurpleNumbershttp://www.bootstrap.org/#9Bhttp://www.eekim.com/software/purple/purple.htmlhttp://collab.blueoxen.net/cgi-bin/wiki.pl?PurpleNumbers
Transclusion:
http://en.wikipedia.org/wiki/Transclusion
Collaborative tagging:
http://en.wikipedia.org/wiki/Collaborative_tagging
The Team:
http://project.cim3.net/wiki/PMWX#The_Team
Can someone suggest on this?
Thanks
--Viral
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 first release candidate of PHP 5.2.6 was just released and can be
downloaded from http://downloads.php.net/ilia/. Please try this
release candidate against your code and let us know if any regressions
should you find any. The goal is to have 5.2.6 out within two weeks
time, so timely testing would be extremely helpful.
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