Hi,
I have just joined, I am from mumbai, india. I would like to get the
articles translated in marathi, my mother tongue. Looking at the effort
and no of volunteers, this will not be usable in any reasonable amount
of time.
That has made me think of alternatives - machine translation. A state
funded institute has a software available but I don't have access to it
yet.
Pl. comment about this approach. Has this been tried for any other
language earlier.
Thanks & regards,
Prasad Gadgil
________________________________________________________________________
Yahoo! India Matrimony: Find your life partner online
Go to: http://yahoo.shaadi.com/india-matrimony
Hello,
As wikipedia is slow at the busy time, I propose to get some new servers for our cluster.
- Some new web servers(3 or 4), P4 2,8Ghz with 2Go of RAM
- A server which could be a backup for nfs server, zwinger, with bigger disk, 80Go is very low, maybe 200 or 250Go
- Upgrading disk of zwinger to 200 or 250Go (or add a new one)
- A db server in 64 bits mode with 4Go of RAM (if we cant make working geoffrin), like this one :
http://www.macomp.com/products/servers/patriot2200.asp
With raid 10 disk system, 4 or 6 drives in raid and 1 stand-by. I prefer 15000rpm disk, but I can understand that they are more expensive
- Maybe another squid server
What do you think of that ?
Shaihulud
This is a MediaWiki programming issue; if you're only interested in
admin stuff, you can safely delete.
So, I'd like to set up a system of hooks and filters for MediaWiki. We
have right now four ways to change how MediaWiki works:
1. Tag extensions. You can add new tags that the parser can
generate code for.
2. Special pages. You can add special pages that do different kinds
of queries.
3. Edit filtering. You can put a pre-filter on editing.
4. Skin changes. You can create new skins.
However, we don't have an easy way to change the behaviour of mainline
functionality. I think it would be a good idea to add some simple hook
processing to MediaWiki, so that extensions can add hooks and run custom
code when something happens.
Consider, for example, an extension to log key actions in the wiki to a
specialized logging system. The extension setup function could look
something like this:
function setup_logging {
global $wgLogFile;
wfAddHook('after_article_save', log_article_save, $wgLogFile);
wfAddHook('after_delete', log_deletion, $wgLogFile);
wfAddHook('after_user_ban', log_user_ban, $wgLogFile);
}
By calling the wfAddHook() function, the extension asks that a function
get called if/when an event happens. wfAddHook() takes three arguments:
the name of the event (say, after an article is deleted), a function to
call, and an optional data block that can be used by the function. This
way, we can use the same function for different hooks or different
actions, like:
wfAddHook('after_article_save', irc_notify, 'brion');
wfAddHook('after_article_save', irc_notify, 'TimStarling');
A hook function would look something like this:
function log_deletion(&$params, $data) {
$title = $params['title'];
$dbkey = $title->getDBkey();
$filename = $data;
foo_log_message("Article '$dbkey' deleted.", $filename);
return true;
}
The $params argument here is an associative array of the event-specific
parameters. We use this instead of named arguments so that the same
function could be used for different events. The $data is just the data
item that was used when the hook was added.
Hooks can return four possible values:
* true -- the hook has operated successfully and subsequent hooks
should be run
* false -- the hook has operated successfully but no subsequent
hooks should be run
* "some string" -- an error occurred; processing should stop and
the error should be shown to the user
* NULL -- the hook has successfully done the work necessary and
the calling function should skip
The last result would be for cases where the hook function replaces the
main functionality. For example, if you wanted to authenticate users to
a custom system (LDAP, another PHP program, whatever), you could do:
wfAddHook('before_user_login', ldap_login);
# ...
function ldap_login(&$params, $data) {
$user_id = $params['user_id'];
$password = $params['password'];
# log user into LDAP
return NULL;
}
Note that a reference to the parameters is passed to the hook function:
the hook could theoretically change its parameters, like so:
wfAddHook('before_article_save', reverse_title);
# ...
function reverse_title(&$params, $data) {
$old_title = $params['title'];
$params['title'] = Title::makeTitle($old_title->getNamespace(), strrev($old_title->getDBkey()));
return true;
}
A calling function or method would use the wfRunHooks() function to run
the hooks related to a particular event, like so:
class Article {
# ...
function submit(...) {
$params['title'] = ...;
$params['user'] = ...;
$params['section'] = ...;
$params['is_new'] = ...;
if (wfRunHooks('before_article_save', $params)) {
# save the article
wfRunHooks('after_article_save');
}
}
wfRunHooks() returns true if the calling function should continue
processing (the hooks ran OK), or false if it shouldn't (an error
occurred, or one of the hooks handled the action already). Checking the
return value matters more for "before_*" hooks than for "after_*" hooks.
The big advantage to this event-handling approach is that we can start
isolating site-specific features into extension files. The "mainline"
code only concerns itself with "mainline" features, and "extension" code
can handle more exotic ones. It simplifies our mainline code,
centralizes extension features into one easy-to-comprehend package, and
hopefully improves our quality and reliability. (The simpler our
mainline code is, the fewer bugs it will have; the easier it is to read,
the more people will want to help maintain it.)
It should also help us evaluate/implement experimental new features, and
obviate the need to patch the mainline code to do so. Lastly, it could
let us move little-used features out to extension files to simplify the
main code.
There are disadvantages, of course, too. If MediaWiki is only supposed
to work for a single wiki installation, or multiple installations that
should behave exactly the same, then the hooks code is unnecessary -- we
should just code it all in the mainline code. There's also some
additional complexity in the mainline code in setting up the parameters
and calling the hook functions; this can be balanced against the
complexity of adding each extension's code into the mainline functions.
Finally, there is a lot of documentation that would need to be done to
say 1) where hooks are defined and 2) what parameters they provide.
Anyways, I'm going to post this to meta, and implement it for 1.4. But I
figured this would be a good forum for discussion -- hopefully making
the feature better.
~ESP
--
Evan Prodromou <evan(a)wikitravel.org>
Nick Pisarro here...after disappearing into the woodwork since the
Spring...
I recently upgraded our MediaWiki run site to 1.3.7. In a fit of
programming frenzy, I have implemented a new feature; the ability to edit
the summary and Minor Edit flag of an article revision. Assuming I still
have the proper access rights to 'phase3' on SourceForge, I would like to
merge my feature into the head branch and upload it assuming enough of you
find the feature worthwhile.
The purpose of the feature is to allow people to correct errors they may
have made in a summary or to add one when the may have forgotten to--a
problem I have personally all the time. Sysops have the option to clean up
offensive language in summaries.
I have attached screen shots of the feature in action. I don't know if the
mailing list program will forward them.
Features.
* The feature is controlled by a flag in Default/LocalSettings.
* You may only edit the summaries of revisions you have made, except for
SysOps, who may edit any summary. (Summaries are referred to in the PHP
code as "comments".) Anonymous users, and hence users not logged in, may
not edit summaries.
* In the History listing and Contributions listings I have put a small
icon next to the summary on lines a user may edit the summary of.
* Clicking on the icon will bring up a page titled after the article being
edited and subtitled "Editing summary of revision...". The page has an
edit field and check box for adjusting the summary and/or changing the
Minor Edit flag. A user my click "Save" or "Cancel".
* A double check is done as part of making the database update, that the
user is still logged in and that they are the author of the revision, if
they are not a SysOp. This is done to thwart any evil robots spoofing a
submit of the edit page.
* The page is refreshed with a confirmation or cancellation message and a
link back into the History or Contributions page the user came from. After
ten seconds the user is flipped back automatically in a way that is
similar to Login/Logout.
* The edit page is implemented by a new file--EditComment.php. Internally
I modified the function OutputPage::returnToMain() to allow flipping back
to exactly where you came from, rather than always to a main article page.
Issues: Because there are no histories of summaries and hence no
'reversions' I thought there were too many security risks in letting
anonymous users edit their summaries (which may not actually be theirs),
or letting logged in users edit summaries other than there own.
Changing a summary will NOT change its listing in Recent changes. This is
because this is a log of past events and is a copy of the original
summary, not an actual reference to it. I thought it might cause too big
of a performance hit to try to fix up the Recent changes log, and perhaps,
philosophically not a good idea.
Future enhancement: Log changing the summary in Recent changes. This might
require a database format change, so I did not want to attempt it.
If desired, I could convert this message to an article on
meta.wikimedia.org.
User:Nick Pisarro, Jr.
Is there any way to generate a table of contents to disaplay on the main
page och any special page.
I am using MediaWiki for documentation and dictionary on our intranet
and a good overview of all the topics would be great.
Any work done on this kind of feature?
/Peter
I've a question, I registered an account on MediaZilla, and for some
reason the e-mail that has my password is... not appearing. Anywhere. I
keep checking my POP server (yes I did put in the right address), but
Thunderbird says there's nothing on the server. So, did the server
forget about my registration or does it just take a long time?
Hi all, I am wondering if there is any interest in some mods
to enhance MediaWikis ability to be multi-hosted from a
single core of code ?
I've done this a few times now with phpBB2 and Wordpress and
mostly have the "pattern" down on how to do it. I just spent
an hour with MediaWiki and there are not too many changes
involved. Is there any interest in this kind of thing and if
so where is the best place to post the details... wiki, here ?
--markc
Brion,
you have recently introduced two new variables (see Subject) without
consulting me. This action put a lot of pressure to me, as I am working
on a perfect Email Authentication by using the principles as fully
described in
http://bugzilla.wikipedia.org/show_bug.cgi?id=866
[Bug 866] Email authentication by a dummy "forgot my password" cycle
which is almost ready. I would kindly like to ask you that you inform my
about such variables, which influence my work.
Please can you explain to me the reasons for your variables - they make
no sense without an ***email authentication*** as for example disclosed
in my http://bugzilla.wikipedia.org/show_bug.cgi?id=868 .
In this bugzilla I describe the difference between an un-authenticated
address ("dirty") which is only be used for "I forgot my password"
cycle, wheras authenticated "clean" addresses are used for EmailUser and
Email Notification (my enotif patch
http://bugzilla.wikipedia.org/show_bug.cgi?id=454 ). The Enotif mailing
actions can be enabled or disabled by options in DefaultSettings.php and
- if enabled - any user sees a corresponding option in his/her user
preferences, where he can opt-in or opt-out to receive notification on
changes of his/her watched pages and/or user_talk page.
Everything is publically disclosed in http://meta.wikipedia.org/Enotif
and I invite you all to spend some minutes for reading it.
So, developers and people tracking CVS will have noted that I've added
event-hooking facilities to MediaWiki. There's a framework for adding
hooks to events, documentation, and a sample extension that uses event
hooks to log events to the syslog facility. I plan to keep adding events
to the codebase (and event hooks to the Syslog extension) over the next
few days as I think of them and figure out how to implement them.
I think that RC patrol would be a stellar example of a feature that
should be implemented using event hooks. First, it's optional. Second,
the enabling code for it is spread over several different functions in
several different modules -- it would be more comprehensible and
maintainable if it were all consolidated in one place. Finally, it's
reactive to "core" events like saving and viewing articles.
My question: would anyone be freaked out if I migrated RC patrol to a
single module using event hooks? I'm not 100% sure it can be done, but I
think it would be a worthwhile exercise.
~ESP
--
Evan Prodromou .O.
http://bad.dynu.ca/~evan/ ..O
evan(a)bad.dynu.ca OOO