Hi all,
For some time, with some friends we have been playing with a
prototype that makes it possible to search content from Mediawiki by
sending text messages (SMS) from your phone. You send your search
term to to the server and after receiving the text message the server
(Asterisk) makes a call back to you and plays the audio content (if
there is audio) or text to speech will read you the text content
found fro the corresponding article. During the call you can navigate
in the article with the DTMF/touchtone key presses. For instance you
can jump to next section and record audio to any of the sections.
Right now we do not have the energy needed to develop the prototype
further. For this reason we would be happy to give it as a project
for some developer interested in to take a leadership of it.
The development site is in here:
http://dev.mobiled.org/trac/
A blog and background information about the project is here:
http://www.mobiled.org
Please, let me know if you (or you know someone who) could be
interested in to work with this.
We are happy to keep on hosting the development site (http://
dev.mobiled.org/trac/), the SVN and give all support one may need to
get on working with this.
The prototype is in a stage that one can set it up, but the whole
thing is not packaged in a way that other people could take it in use
in any easy way. There are also some specific hardware requirements
and you also needs a phone line to make it work.
So, for what one can use the audio mobile wiki?
We have tested it with Wikipedia content and in a way it works. You
can very check pretty fast some basic facts with it when not close to
web. For instance, if you just want to know some basic things about
some country the Wikipedia format works for this purpose pretty well
also when used with this.
We also have made some school pilots where students were providing
content to the wiki in form of "podcasts" they recorded with the
phone. It was fun and also worked out pretty well.
RIght now we are writing a paper claiming that most likely the mobile
audio could work nicely as some kind of craigslist in places where
there aren't internet connections but mobile phones. One could have
in a wiki server local news, classified, jobs, housing, for sale etc.
- all content mainly provided by the people with their phone and by
recording their ads to the server under the right search term.
Why we think that this is important?
Most people in the world do not have an internet connection. Most
people have mobile phones - those simple ones with text message and
voice.
Why we are no more interested in to develop this?
We are, but we simply do not have the right skills set: very limited
knowhow of Mediawiki and Asterisk. From our side the MobilED research
- we are a research group - is pretty much done. What we did was
contextual inquiry, participatory design, prototype development and
piloting of the idea with real people. We also have reported this
work in various forums. However, event with this announcement of
looking for a main software developer for the open source project we
are not going to leave the MobilED totally behind. We still want to
be involved in it and do more our kind of research when there is a
need for it.
Best regards,
- Teemu
Dear all,
In mediawiki the standard link tag looks like:
> * [[ <link> "link text "]] *
>
I would like to add a different link tag (lets say *[r8[[ <link> "link text
"]]r8] * ) which can then be parsed like a normal link but this will have
a rating function next to it. Many people have built rating extensions so
much of the work has already been done for me. I simply want to be able to
allow people to rate links. Any suggestions on how I can find what part of
mediawiki parses the links?
Thanks
Jon
I'd just like to let the many a non-committer extension developer here
know that I am open for committing any sane extension (Yes, DPL does
count as sane in this category ;) heh...) into Subversion.
Nothing beats revision management. Even if it's not Wikimedia's SVN. I
even have my own repo for Wiki-Tools which I commit my variety of
extensions into. Once I look over SSH keys and a bit more on security
I'd even be willing to give other people commit access for those who
can't take the long wait to being able to get commit access to
Wikimedia's SVN.
But wherever it's managed, there is nothing like being able to
svn-update to grab all the new changes to extensions and keep yourself
running with good code. I personally get a very bad taste in my mouth
when I see an extension on MediaWiki.org which I am forced to use some
manual method of grabbing the data just to install it. I tend to avoid
installing those if possible. But not only does it ruin the taste of the
extension, it also means there aren't as many people poking in the code
and making sure it works right, and it's up to usable standards. Plus
Wikimedia's SVN has Betawiki's support.
So, I'm here basically saying... "If you have a sane extension up on
MediaWiki.org, I'd be happy to help commit it to Subversion so that
myself and other people can poke at it, translate it, and keep it nicely
working with MediaWiki. And also make it easier for people to get ahold
of the code. And I'll even be happy to apply any patches you have to
update your extension with new features you've made". Of course, I'm not
going to commit something completely stupid, but there is a small bit of
room for extensions which need a bit of standards tweaking after being
committed.
And yes, I'll probably periodically poke various developers as I find
extensions I personally would like to install, and ask them if they
would let me commit the extension to SVN, even just to make sure that I
can use a reliable extension rather than something left on the wiki.
--
~Daniel Friesen(Dantman) of:
-The Gaiapedia (http://gaia.wikia.com)
-Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG)
-and Wiki-Tools.com (http://wiki-tools.com)
All,
Does anyone know of a non-intrusive, through extensions way of managing
additional data on a user login form? I have customized the user creation
form
with this hook --->> customUserCreateForm , but now that I have extra
fields, how do I go about writing those to the database without hijacking
the $user->creatNew method?
Thanks in advance for any help,
- Chris
On Sat, May 10, 2008 at 10:20 PM, <nad(a)svn.wikimedia.org> wrote:
> In MySQL the standard way of inserting data into rows exhibiting AUTOINCREMENT columns is simply to use a ''NULL'' value which will be ignored. In MSSQL however assigning a ''NULL'' to an ''IDENTITY'' column is not allowed, instead the best way is not to include those items in the list of columns to be updated at all.
>
> To get round this in the MediaWiki MSSQL layer, I've modified the insert wrapper in the ''DatabaseMssql'' class to check if the primary key is used in the insert and remove it if so. It checks this by assuming that the primary key will be of the same name as the table but with ''_id'' on the end, and that it will the first item in the list of columns to update.
It would be best to raise some kind of warning when this condition
occurs, preferably in the MySQL code path too, so that developers
using MySQL with notices enabled can notice and fix it. Just not
specifying the column to begin with works fine with MySQL too, so it
should be used if it's more compatible.
> MySQL implicitly casts NULL assignments to NOT NULL columns to an empty string or zero value accordingly, but MSSQL raises an error instead. This is a big problem within the MediaWiki environment because the code relies heavily on this implicit NULL casting. I've tried to get round the problem by replacing NULL's with empty strings from update and insert queries, and MSSQL is happy to cast the empty string to a numeric zero if necessary.
How does PostgreSQL handle this? If you know what type the column is,
you can cast it in the application logic. Again, it would seem better
to implement this checking in the cross-database code and raise
warnings if it comes up so it can be fixed on a case-by-case basis.
This doesn't work with MySQL strict mode either, which is the default
under some circumstances last I heard.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
nad(a)svn.wikimedia.org wrote:
> + * This script is the MSSQL Server database abstraction layer
> + * - Licenced under LGPL (http://www.gnu.org/copyleft/lesser.html)
> + * - Author: [http://www.organicdesign.co.nz/nad User:Nad]
Hrm...
What version LGPL? Are there any compatibility issues between GPLv2 and
LGPL mystery version?
- -- brion vibber (brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkgo0LUACgkQwRnhpk1wk44plgCePdDELbJTp3MRQFTsDhwQUgo2
eUYAoJRPFN5gr+gSkieZFXZZPdP3WOqB
=TOwT
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
skizzerz(a)svn.wikimedia.org wrote:
> Revision: 34594
> Author: skizzerz
> Date: 2008-05-10 18:31:05 +0000 (Sat, 10 May 2008)
>
> Log Message:
> -----------
> Fix for bug 13677
Don't forget to describe the purpose of you change with *words* too so
people don't have to hop around to bugzilla to figure out what you're
doing. :)
- -- brion vibber (brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkgozvkACgkQwRnhpk1wk45etQCfUNd//LP62bhHZ/fBYK7AtiJJ
QWcAnjAMKUIxlIgFJkbaSkgeon+ZOVH7
=CZEx
-----END PGP SIGNATURE-----
OTRS often receives vandalism reports regarding pages that were fixed
several days ago. Looks like Squids systematically fail to purge. Is
there something could be done about that?
--
Max Semenik ([[User:MaxSem]])
Hi All,
A while ago there was a thread about keeping maintenance scripts tested
and up to date, but I haven't heard anything about that effort recently.
I am trying to upgrade a bunch of wikis from 1.9.2 to at least 1.11, but
we use dumpHTML heavily. Can anyone confirm that dumpHTML still works
as expected for more recent versions of MediaWiki?
Thanks!
Courtney Christensen