I apologize if this is not the right forum to discuss this topic.
I'm planning to hire someone to make the following modifications to
the MediaWiki source code (1.5 beta version). I'd be interested in
getting feedback from this list about the the major change that I want
implemented: "structured namespaces." I want to keep the
implementation as simple as possible in order to reduce development
costs, and also want to keep things in the spirit of where MediaWiki is
going long-term, in case you wanted to eventually fold the code for
structured namespaces into the main codebase.
And in case someone from this list is interested in working on the
project for me, I've included the other changes I need someone
to make as well.
Thanks in advance for looking this over,
-dallan
General requirement: In order make it easier for me to update to later
MediaWiki versions in the future, as few changes to the existing
scripts should be made as possible. Instead, the modifications should
be implemented generally by adding hooks into the existing functions
that call out to new classes and functions.
Major Changes: structured namespaces
You'll notice that several types of Wikipedia pages (e.g., countries
and US states) have infoboxes to display particular data elements. I
want to carry this one step further by assigning a specific structure
to certain namespaces. All pages in a "structured namespace" would
contain data elements that conform to the specific schema/DTD that has
been assigned to that namespace. The data would be included in the
page content before the regular text of the page. This affects how
the page is displayed and how it is edited. Special functions would
be associated with the namespace for page display and editing, as
described below. The "diff" view to compare two versions of a page
would not need a new function. By saving data elements at the top of
a page in a pretty-printed XML format, diffs running over the entire
page (including both data element and regular text portions) should
make reasonable sense to the user.
Specifically, I would like four enhancements made in this area:
(1) When a page in a structured namespace is displayed, a call-out to
a namespace-specific display function is made to display the data
elements on the page. The regular text of the page (after the data
element portion) is then displayed using the existing functionality.
(2) When a page in a structured namespace is edited, a call-out to a
namespace-specific edit function is made to generate HTML form fields
for editing the data elements on the page. The regular text of the
page is then placed in the normal edit textbox using the existing
functionality.
(3) Before previewing or saving an edited page in a structured
namespace, a call-out to a namespace-specific generation function is
made to generate the XML to insert into the page from the user-entered
data. In addition, the generation function may generate errors, in
which case if the user pressed "save" the "preview" page should be
shown instead (i.e., save should be disallowed if there are errors),
and the errors should be listed on the preview page.
(4) When a page in a structured namespace is saved, a call-out to a
namespace-specific propagation function is made to propagate data
elements to related pages if necessary. This callout should be handed
both the current as well as the previous version of the data elements
for the page. Suppose for example that a structured namespace
contained pages for places, that one of the data elements on a place
page was its enclosing "parent" place, and that another of the data
elements on a place page was a list of subordinate "child" places
which was non-user-editable - that the way to edit this list of child
places was through changing the parent place of a child. Then if
someone were to change the parent place of a child, it would need to
be removed from the list of children in the previous parent place and
added to the list of children in the new parent place, so the
propagation function would read the page for the previous parent
place, update its list of child places, then read the page for the new
parent place and update its list of child places. The propagation
function must be done in the same transaction as the page save, so
that either both succeed or both fail. It must also be called as
part of page deletion.
Other changes:
(1) Display, edit, generation, and propagation functions for a "given
name" structured namespace. This namespace contains the following data
element.
* Related names: one or more names.
When displayed, each related name displays as a link to another "given
name" page (the page is possibly non-existent). In editing, the names
should be entered as a list, one per line. To validate, ensure that
names contain only alphabetic characters, spaces, and single quotes,
no wiki/html markup. No propagation is needed.
(2) Display, edit, generation, and propagation functions for a
"surname" structured namespace. This namespace contains the same
elements and functions as the "given name" namespace.
(3) Display, edit, generation, and propagation functions for a "place"
structured namespace. This namespace contains the following data
elements.
* Preferred name
* Parent: link to title of the parent (enclosing) place; e.g., for US
States, this is the title of the USA country page. This page must exist.
* Date range: start - end year
* Type of place: country, state, province, county, city, etc.
* Previous parents: list of links to titles of previous parent places, along
with a year range (from - to) for which this was the parent. Each of these
pages must exist
* All names: a list of all variant names/common misspellings and their
sources (i.e., the atlas/gazetteer giving this name as the name of the
place) that this place has been known by over time.
* Latitude and longitude
* Population
* See-also places: a list of links to related places and the reason that
each is related to this place. Each of these pages must exist.
* Child/subordinate places: A list of links to all places that list this
place as their Parent, shown grouped by Type.
This is the most complex namespace. To be a little more precise, an XML
grammer for the data elements is:
element place {
element preferredname { text },
element parent { text },
element daterange {
element from { text },
element to { text }
},
element type { text },
element previousparents {
element previousparent {
element parent { text },
element from { text }?,
element to { text }?
}*
},
element allnames {
element allname {
element name { text },
element source { text }?
}+
},
element latitude { text },
element longitude { text },
element population { text },
element see_also_places {
element see_also_place {
element place { text },
element reason { text }?
}*
},
element childplaces {
element childplace {
element place { text },
element type { text }
}*
}
}
Display should show these data elements in an infobox on the
right-hand side of the screen. Editing previous parents, all names,
and see-also places should use textboxes, listing one entry per row,
with |'s separating the fields on a row. (I think this makes editing
these complex fields relatively easy.) Validation should parse the
textbox rows and ensure that numeric fields are numeric. Also, no
wiki/html markup should be allowed in any of the data elements. Child
places cannot be user-edited. Instead, they are derived from upon
each place's Parent place, and propagated as described in the
introduction.
(4) Display, edit, generation, and propagation functions for a "resource"
structured namespace. This namespace contains the following data elements.
* Category(s): one or more of: census, birth, marriage, death, obituary,
etc.
* Access: one of: web site, web form, microfilm, book, etc.
* Place(s): one or more place pages. The place pages must exist.
* Surname(s): one or more surname pages. The surname pages do not have to
exist.
* Year range: from - to: both must be 4-digit years, with from <= to
* Coverage: one of: good, fair, poor, or unknown
* Location:
- if Access is web site or web form, this must be a URL;
- otherwise this can be anything.
Display should show these elements in an infobox on the right-hand
side of the screen. Edit function creates a multi-select list for
category, a drop-down list for access and coverage, textboxes for
places and surnames (with one entry per line), text fields for from
and to years, and a textbox for location (no wiki/html formatting
in any data element). No propagation is necessary.
(5) New skin - need a new CSS skin (describe later).
(6) Need a "special page" that displays all pages in the surname
namespace. This should use the AllPages special page script,
restricted to pages in the surname namespace. The only difference is
that I want the URL for this "all surname pages" to have just a single
parameter, which is the starting name (from=).
(7) Only registered users should be able to create/edit pages in the 4
namespaces mentioned above.
(8) Only sysops should be able to create/edit pages in other namespaces
(outside of the 4 namespaces mentioned above).
(9) User registration should require email confirmation. That is, as
part of the registration process, an email should be sent to the user
containing a special URL that they need to click on in order to complete
their registration.
(10) There is an extension to MediaWiki that allows daily digest emails
to be sent instead of an email for every page change. You need to
install this option and make sure that if the user elects to be notified
of changes to pages in their watchlist, that they are sent digests rather
than separate emails for each page changed.
(11) Full-text search: Add a "special page" that provides full-text
searching of pages by calling a REST-based search interface that I
will provide. Essentially, you'll make an HTTP call with a URL that
includes the user-entered search string, namespace, start#, and
the #results to display. You will passed back an XML result set
containing a total count along with a list of PageURLs and context
strings to display.
Brion,
Thanks for your reply. I have subscribed to the list, as you suggested.
I don't understand what you mean by polluting my name space. My URL
*is* a virtual directory. I use subdomains to keep my domain space
"unpolluted":
http://kerim.oxus.nethttp://wiki.oxus.nethttp://keywords.oxus.nethttp://forums.oxus.net
This seems like a pretty standard practice on many webservers, not
sure I understand what MediaWiki has against it. I have never had any
problems with this, except for WikiMedia 1.4.
In fact, you helped me set up the .htaccess when I installed
WikiMedia 1.5. (At the time I had problems with domain forwarding
which you helped me resolve.)
The settings from my old LocalSettings.php and .htaccess file (both of
which I have saved) do not seem to work with 1.5.
Thanks for your help!
Kerim
From: Brion Vibber <brion <at> pobox.com>
Subject: Re: Short URLs
Newsgroups: gmane.science.linguistics.wikipedia.technical
Date: 2005-07-09 18:28:23 GMT (1 hour and 9 minutes ago)
Kerim Friedman wrote:
> I just upgraded my Wiki <http://wiki.oxus.net> from 1.3.x to 1.4.x. Everything
> went fine, with one major problem: I no longer have the same URL structure I
> used to have. Before my site urls looked like this:
>
> http://wiki.oxus.net/Main_Page
I strongly recommend against this, as it pollutes your URL namespace and
may create conflicts. You should always put your rewrite area in a
virtual directory.
> now they look like this:
>
> http://wiki.oxus.net/index.php/Main_Page
That's the default. Did you throw away your old LocalSettings.php?
> I tried following the instructions on this page:
>
> http://meta.wikimedia.org/wiki/Using_a_very_short_URL
>
> But they do not work.
Is that the same as what you did before?
> I did some searching but couldn't find any solution that works with Apache
> 1.3.x, so I thought I'd write to the group to see if anywone has figured out a
> work around?
The rewrite configuration would be exactly the same on 1.3.x and 2.0.x
so far as I know.
> Please write to me off-list at oxusnet+software [at] gmail.com.
Please subscribe to mailing lists that you post to so your message
doesn't go in the spam queue. :)
-- brion vibber (brion <at> pobox.com)
_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> wikimedia.orghttp://mail.wikipedia.org/mailman/listinfo/wikitech-l
I'm having a second issue on my wiki <http://wiki.oxus.net/> as well. Since my
upgrade from 1.3.x to 1.4.x, I now get the following error message after saving
changes to an article. The article changes are saved, it just doesn't seem like
the site is properly navigating back to the article.
----begin error message------
Database error
>From KerimWiki
A database query syntax error has occurred. This may indicate a bug in the
software. The last attempted database query was:
(SQL query hidden)
from within function "SearchUpdate::doUpdate". MySQL returned error "1016: Can't
open file: 'searchindex.MYI'. (errno: 145) (localhost)".
Retrieved from "http://wiki.oxus.net/index.php/Main_Page"
----end error message------
Please reply to me off list at oxusnet+software [at] gmail.com.
Thanks for your help.
Kerim
I just upgraded my Wiki <http://wiki.oxus.net> from 1.3.x to 1.4.x. Everything
went fine, with one major problem: I no longer have the same URL structure I
used to have. Before my site urls looked like this:
http://wiki.oxus.net/Main_Page
now they look like this:
http://wiki.oxus.net/index.php/Main_Page
I tried following the instructions on this page:
http://meta.wikimedia.org/wiki/Using_a_very_short_URL
But they do not work. It seems that the problem is that I am using a virtual
host/commercial server which is still using Apache 1.3.x not 2.x. I even tried
using the "kludge" method on the page, but it did not work.
I did some searching but couldn't find any solution that works with Apache
1.3.x, so I thought I'd write to the group to see if anywone has figured out a
work around?
Please write to me off-list at oxusnet+software [at] gmail.com.
Thanks for your help.
Kerim
Can I batch rollback 20 or 30 pages (which were spammed on 7th July)?
I am in the process of uppgrading from 1.5 beta1 to beta3.
Gordo
--
"Think Feynman"/////////
http://pobox.com/~gordo/
gordon.joly(a)pobox.com///
Hey all,
There's been some talk about natural
language wikis and the formation of
new ones over at the Wikipedia-l.
I started a thread on adding Ladino
wikis and got some good feedback
as to what to do in the next steps.
Well, we're ready for the step where
we need to ask one of our hard-at-work
developers for help in making the space
sub-domain available:
http://lad.wikipedia.org
and
http://lad.wiktionary.org
There are five users who support it,
one is a (N) speaker, I'm quite fluent,
the other's know Standard Spanish
or Interlingua, so following the articles
and making corrections would be a
great exercise too. But most importantly
the addition of these wikis will help give
the Ladino community another great
forum for the presentation of its heritage
and the continuation of the language.
There are 160,000 fluent speakers,
200,000 counting those who grew
up with the language but aren't
active users of it. There are broad-
casts on TV and radio in several
countries, Spain, Turkey, Israel, etc.
and many periodicals in Ladino.
A Ladino Wiki would certainly find
the support of many and the praise
of older folks who've endeavored to
keep their language and culture alive.
So it is with high hopes and definite
expectations of growth that I request
the help of one of our developers in
setting up the space for these wikis.
Ladino Wikipedia and Ladino Wiktionary.
Who may be able to help us?
Thanks, with regards,
Jay B.
User:ILVI
ilooy.gaon(a)gmail.com
Hi,
I have the following in my LocalSettings.php:
$wgUseTeX = true;
$wgMathPath = "{$wgUploadPath}/math";
$wgMathDirectory = "{$wgUploadDirectory}/math";
$wgTmpDirectory = "{$wgUploadDirectory}/tmp";
$wgTexvc = "/c/wp/wiki/math/texvc";
I have made sure that "/c/wp/wiki/math/texvc" is a valid executable.
Also I have installed tetex-bin (which supposedly includes both latex
and dvips) and imagemagick.
However, I get the same behaviour as if TeX was turned off
("<math>1+1=2<math>" in the wiki page).
I use Debian GNU/Linux 3.1.
Any help?
Thanks,
Timwi
I propose you upgrade at least to 1.4.6+enotifwiki3.11
see sourceforge !
bugzilla-daemon(a)mail.wikimedia.org schrieb:
>http://bugzilla.wikimedia.org/show_bug.cgi?id=2742
>
>
>
>
>
>------- Additional Comments From stas-fomin(a)yandex.ru 2005-07-08 10:47 UTC -------
>I think that the bug severity="minor", and I will be completely satisfied, I the
>bug will be fixed with Target Milestone=1.5.
>I just want to notify developers about this bug.
>I should wait 1.5 release (I our company we use 3 installations of MediaWiki
>"1.4.5+ENotif 2.0+our patches"), this bug is not so important for us to remerge
>ENotif in MediaWiki again.
>Thank you for quick reply.
>
>
>
(What is) EnotifWiki ?
- Enotif means "e-mail notification"
- is a special edition of MediaWiki
- very close and fully based on it
- permanently maintained
- and offers enhanced e-mail notification functions and some more gadgets.
http://sourceforge.net/projects/enotifwiki/ offers recent maintenance
release of EnotifWiki for
- MediaWiki 1.4.6 or
- MediaWiki 1.5beta3 (this version is recommended by me)
What distinguishes EnotifWiki from MediaWiki ?
* e-mail notifcation also for _new_ pages (users can opt-in/out)
* "You have new messages" also shown for new content on _User_ pages
(EnotifWiki versions for MediaWiki 1.5 versions)
* Recent Changes, Page History lines of watched pages have direct links
to the difference view between the current and your last-seen version
* garish green "updated" markers fly on your not-yet-seen revisions of
watched pages
The differences between EnotifWiki and MediaWiki become smaller and smaller.
Documentation and screenshots: http://meta.wikipedia.org/wiki/Enotif