Dear sir,
I am doing the project voice based home automation. I have tried to convert
the voice into text.But i am not able to code in matlab properly. I saw the
similar project in this link
http://www.softwarepractice.org/wiki/Team_D_Speaker_Recognition.
Please can anyone send me the source code for this project. It ll be
helpful to compare my coding with that.
Thanks & Regards
Babu M
Final Year Undergraduate Student
SSN College of Engineering
Chennai
India
I'd like to insert a wide image in the top left corner of my
pages, which is too wide to fit in the logo area at the top of the left
column.
How would I go about adding some space at the top of the page and inserting the image there?
Any comments or suggestions would be appreciated.
Hal Segal
Hi everybody.
We'd like to create a "Contrib" namespace which will be the only namespace where users of "user group" will be allowed to edit or create pages.
We've tried the following, but as a result, when we connect to the wiki as a "user", and when we type Contrib:bobopage in search box, we don't have access to create nor edit this page, even it is located inside Contrib. What did we wrong ? (the namespace is present in box/menu resulting from search, with all others namespaces)
Ac
---------------------- here bellow the code inside LocalSettings.php ---------------------------
# Add CUSTOM namespaces and regulate access to
## Add "Contrib" namespace
$wgExtraNamespaces[500] = "Contrib"; # creation of namespace at 500 indice
$wgExtraNamespaces[501] = "Contrib_talk"; # creation of talk namespace at 500 + 1 = 501 indice
define("NS_CONTRIB", 500); # define a constant for the namespace
define("NS_CONTRIB_TALK", 501); # define a constant for the talk namespace
$wgExtraNamespaces[NS_CONTRIB] = "Contrib";
$wgExtraNamespaces[NS_CONTRIB_TALK] = "Contrib_talk";
$wgContentNamespaces[] = 500; # make the namespace content taken in account by statistics tools
## access to "Contrib" namespace
# block / allow access to custom namespaces defined
$wgGroupPermissions['user']['edit'] = false; # forbid access to users
$wgGroupPermissions['user']['editcontrib'] = true; # give rights to be "editcontrib" to users
$wgNamespaceProtection[NS_CONTRIB] = array( 'editcontrib' ); # give rights to "editcontrib" rights owners
I'm happy to announce the availability of the second beta release of the
new MediaWiki 1.19 release series.
Please try it out and let us know what you think. Don't run it on any
wikis that you really care about, unless you are both very brave and
very confident in your MediaWiki administration skills.
MediaWiki 1.19 is a large release that contains many new features and
bug fixes. This is a summary of the major changes of interest to users.
You can consult the RELEASE-NOTES-1.19 file for the full list of changes
in this version.
Five security issues were discovered.
It was discovered that the api had a cross-site request forgery (CSRF)
vulnerability in the block/unblock modules. It was possible for a user
account with the block privileges to block or unblock another user without
providing a token.
For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=34212
It was discovered that the resource loader can leak certain kinds of private
data across domain origin boundaries, by providing the data as an executable
JavaScript file. In MediaWiki 1.18 and later, this includes the leaking of
CSRF
protection tokens. This allows compromise of the wiki's user accounts, say
by
changing the user's email address and then requesting a password reset.
For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=34907
Jan Schejbal of Hatforce.com discovered a cross-site request forgery (CSRF)
vulnerability in Special:Upload. Modern browsers (since at least as early as
December 2010) are able to post file uploads without user interaction,
violating previous security assumptions within MediaWiki.
Depending on the wiki's configuration, this vulnerability could lead to
further
compromise, especially on private wikis where the set of allowed file types
is
broader than on public wikis. Note that CSRF allows compromise of a wiki
from
an external website even if the wiki is behind a firewall.
For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=35317
George Argyros and Aggelos Kiayias reported that the method used to generate
password reset tokens is not sufficiently secure. Instead we use various
more
secure random number generators, depending on what is available on the
platform. Windows users are strongly advised to install either the openssl
extension or the mcrypt extension for PHP so that MediaWiki can take
advantage
of the cryptographic random number facility provided by Windows.
Any extension developers using mt_rand() to generate random numbers in
contexts
where security is required are encouraged to instead make use of the
MWCryptRand class introduced with this release.
For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=35078
A long-standing bug in the wikitext parser (bug 22555) was discovered to
have
security implications. In the presence of the popular CharInsert extension,
it
leads to cross-site scripting (XSS). XSS may be possible with other
extensions
or perhaps even the MediaWiki core alone, although this is not confirmed at
this time. A denial-of-service attack (infinite loop) is also possible
regardless of configuration.
For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=35315
*********************************************************************
What's new?
*********************************************************************
MediaWiki 1.19 brings the usual host of various bugfixes and new features.
Comprehensive list of what's new is in the release notes.
* Bumped MySQL version requirement to 5.0.2.
* Disable the partial HTML and MathML rendering options for Math,
and render as PNG by default.
* MathML mode was so incomplete most people thought it simply didn't work.
* New skins/common/*.css files usable by skins instead of having to copy
piles of
generic styles from MonoBook or Vector's css.
* The default user signature now contains a talk link in addition to the
user link.
* Searching blocked usernames in block log is now clearer.
* Better timezone recognition in user preferences.
* Extensions can now participate in the extraction of titles from URL paths.
* The command-line installer supports various RDBMSes better.
* The interwiki links table can now be accessed also when the interwiki
cache
is used (used in the API and the Interwiki extension).
Internationalization
- --------------------
* More gender support (for instance in user lists).
* Add languages: Canadian English.
* Language converter improved, e.g. it now works depending on the page
content language.
* Time and number-formatting magic words also now depend on the page
content language.
* Bidirectional support further improved after 1.18.
Release notes
- -------------
Full release notes:
https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob_plain;f=RE
LEASE-NOTES-1.19;hb=1.19.0beta2
https://www.mediawiki.org/wiki/Release_notes/1.19
Co-inciding with these security releases, the MediaWiki source code
repository has
moved from SVN (at https://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3)
to Git (https://gerrit.wikimedia.org/gitweb/mediawiki/core.git). So the
relevant
commits for these releases will not be appearing in our SVN repository. If
you use
SVN checkouts of MediaWiki for version control, you need to migrate these to
Git.
If you up are using tarballs, there should be no change in the process for
you.
Please note that any WMF-deployed extensions have also been migrated to Git
also, along with some other non WMF-maintained ones.
Please bear with us, some of the Git related links for this release may not
work instantly,
but should later on.
To do a simple Git clone, the command is:
git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git
More information is available at https://www.mediawiki.org/wiki/Git
For more help, please visit the #mediawiki IRC channel on freenode.netirc://irc.freenode.net/mediawiki or email The MediaWiki-l mailing list
at mediawiki-l(a)lists.wikimedia.org.
**********************************************************************
Download:
http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.tar.gz
Patch to previous version (1.19.0beta1), without interface text:
http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.patch.gz
Interface text changes:
http://download.wikimedia.org/mediawiki/1.19/mediawiki-i18n-1.19.0beta2.patc
h.gz
GPG signatures:
http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.tar.gz.si
g
http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.patch.gz.
sig
http://download.wikimedia.org/mediawiki/1.19/mediawiki-i18n-1.19.0beta2.patc
h.gz.sig
Public keys:
https://secure.wikimedia.org/keys.html
I would like to announce the release of MediaWiki 1.18.2. Five security
issues were discovered.
It was discovered that the api had a cross-site request forgery (CSRF)
vulnerability in the block/unblock modules. It was possible for a user
account with the block privileges to block or unblock another user without
providing a token.
For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=34212
It was discovered that the resource loader can leak certain kinds of private
data across domain origin boundaries, by providing the data as an executable
JavaScript file. In MediaWiki 1.18 and later, this includes the leaking of
CSRF
protection tokens. This allows compromise of the wiki's user accounts, say
by
changing the user's email address and then requesting a password reset.
For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=34907
Jan Schejbal of Hatforce.com discovered a cross-site request forgery (CSRF)
vulnerability in Special:Upload. Modern browsers (since at least as early as
December 2010) are able to post file uploads without user interaction,
violating previous security assumptions within MediaWiki.
Depending on the wiki's configuration, this vulnerability could lead to
further
compromise, especially on private wikis where the set of allowed file types
is
broader than on public wikis. Note that CSRF allows compromise of a wiki
from
an external website even if the wiki is behind a firewall.
For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=35317
George Argyros and Aggelos Kiayias reported that the method used to generate
password reset tokens is not sufficiently secure. Instead we use various
more
secure random number generators, depending on what is available on the
platform. Windows users are strongly advised to install either the openssl
extension or the mcrypt extension for PHP so that MediaWiki can take
advantage
of the cryptographic random number facility provided by Windows.
Any extension developers using mt_rand() to generate random numbers in
contexts
where security is required are encouraged to instead make use of the
MWCryptRand class introduced with this release.
For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=35078
A long-standing bug in the wikitext parser (bug 22555) was discovered to
have
security implications. In the presence of the popular CharInsert extension,
it
leads to cross-site scripting (XSS). XSS may be possible with other
extensions
or perhaps even the MediaWiki core alone, although this is not confirmed at
this time. A denial-of-service attack (infinite loop) is also possible
regardless of configuration.
For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=35315
Full release notes:
https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob_plain;f=RE
LEASE-NOTES-1.18;hb=1.18.2
https://www.mediawiki.org/wiki/Release_notes/1.18
Co-inciding with these security releases, the MediaWiki source code
repository has
moved from SVN (at https://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3)
to Git (https://gerrit.wikimedia.org/gitweb/mediawiki/core.git). So the
relevant
commits for these releases will not be appearing in our SVN repository. If
you use
SVN checkouts of MediaWiki for version control, you need to migrate these to
Git.
If you up are using tarballs, there should be no change in the process for
you.
Please note that any WMF-deployed extensions have also been migrated to Git
also, along with some other non WMF-maintained ones.
Please bear with us, some of the Git related links for this release may not
work instantly,
but should later on.
To do a simple Git clone, the command is:
git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git
More information is available at https://www.mediawiki.org/wiki/Git
For more help, please visit the #mediawiki IRC channel on freenode.netirc://irc.freenode.net/mediawiki or email The MediaWiki-l mailing list
at mediawiki-l(a)lists.wikimedia.org.
**********************************************************************
Download:
http://download.wikimedia.org/mediawiki/1.18/mediawiki-1.18.2.tar.gz
Patch to previous version (1.18.1), without interface text:
http://download.wikimedia.org/mediawiki/1.18/mediawiki-1.18.2.patch.gz
Interface text changes:
http://download.wikimedia.org/mediawiki/1.18/mediawiki-i18n-1.18.2.patch.gz
GPG signatures:
http://download.wikimedia.org/mediawiki/1.18/mediawiki-1.18.2.tar.gz.sighttp://download.wikimedia.org/mediawiki/1.18/mediawiki-1.18.2.patch.gz.sighttp://download.wikimedia.org/mediawiki/1.18/mediawiki-i18n-1.18.2.patch.gz.
sig
Public keys:
https://secure.wikimedia.org/keys.html
I would like to announce the release of MediaWiki 1.17.3. Five security
issues were discovered.
It was discovered that the api had a cross-site request forgery (CSRF)
vulnerability in the block/unblock modules. It was possible for a user
account with the block privileges to block or unblock another user without
providing a token.
For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=34212
It was discovered that the resource loader can leak certain kinds of private
data across domain origin boundaries, by providing the data as an executable
JavaScript file. In MediaWiki 1.18 and later, this includes the leaking of
CSRF
protection tokens. This allows compromise of the wiki's user accounts, say
by
changing the user's email address and then requesting a password reset.
For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=34907
Jan Schejbal of Hatforce.com discovered a cross-site request forgery (CSRF)
vulnerability in Special:Upload. Modern browsers (since at least as early as
December 2010) are able to post file uploads without user interaction,
violating previous security assumptions within MediaWiki.
Depending on the wiki's configuration, this vulnerability could lead to
further
compromise, especially on private wikis where the set of allowed file types
is
broader than on public wikis. Note that CSRF allows compromise of a wiki
from
an external website even if the wiki is behind a firewall.
For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=35317
George Argyros and Aggelos Kiayias reported that the method used to generate
password reset tokens is not sufficiently secure. Instead we use various
more
secure random number generators, depending on what is available on the
platform. Windows users are strongly advised to install either the openssl
extension or the mcrypt extension for PHP so that MediaWiki can take
advantage
of the cryptographic random number facility provided by Windows.
Any extension developers using mt_rand() to generate random numbers in
contexts
where security is required are encouraged to instead make use of the
MWCryptRand class introduced with this release.
For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=35078
A long-standing bug in the wikitext parser (bug 22555) was discovered to
have
security implications. In the presence of the popular CharInsert extension,
it
leads to cross-site scripting (XSS). XSS may be possible with other
extensions
or perhaps even the MediaWiki core alone, although this is not confirmed at
this time. A denial-of-service attack (infinite loop) is also possible
regardless of configuration.
For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=35315
Full release notes:
https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob_plain;f=RE
LEASE-NOTES;hb=1.17.3
https://www.mediawiki.org/wiki/Release_notes/1.17
Co-inciding with these security releases, the MediaWiki source code
repository has
moved from SVN (at https://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3)
to Git (https://gerrit.wikimedia.org/gitweb/mediawiki/core.git). So the
relevant
commits for these releases will not be appearing in our SVN repository. If
you use
SVN checkouts of MediaWiki for version control, you need to migrate these to
Git.
If you up are using tarballs, there should be no change in the process for
you.
Please note that any WMF-deployed extensions have also been migrated to Git
also, along with some other non WMF-maintained ones.
Please bear with us, some of the Git related links for this release may not
work instantly,
but should later on.
To do a simple Git clone, the command is:
git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git
More information is available at https://www.mediawiki.org/wiki/Git
For more help, please visit the #mediawiki IRC channel on freenode.netirc://irc.freenode.net/mediawiki or email The MediaWiki-l mailing list
at mediawiki-l(a)lists.wikimedia.org.
**********************************************************************
Download:
http://download.wikimedia.org/mediawiki/1.17/mediawiki-1.17.3.tar.gz
Patch to previous version (1.17.2), without interface text:
http://download.wikimedia.org/mediawiki/1.17/mediawiki-1.17.3.patch.gz
Interface text changes:
http://download.wikimedia.org/mediawiki/1.17/mediawiki-i18n-1.17.3.patch.gz
GPG signatures:
http://download.wikimedia.org/mediawiki/1.17/mediawiki-1.17.3.tar.gz.sighttp://download.wikimedia.org/mediawiki/1.17/mediawiki-1.17.3.patch.gz.sighttp://download.wikimedia.org/mediawiki/1.17/mediawiki-i18n-1.17.3.patch.gz.
sig
Public keys:
https://secure.wikimedia.org/keys.html
In the past few months, I've needed to test gadgets that are used on WMF
sites, but didn't have an easy way to copy them from, say, Commons to
Beta in Labs.
I hacked something together and then forgot about it until Chris McMahon
(the WMF's new QA guy) wanted something similar for one of his test
wikis a couple of weeks ago. I couldn't find it, so last night I
rewrote the script from scratch.
The script is pretty ugly and, normally, I might commit it to SVN and
work on it there, but we're in the process of moving to Git, so I've
gone ahead and created a gitorious repository:
https://gitorious.org/wiki-gadgets
Lots of hard-coding that could be cleaned up, and it could use the API
to copy from one wiki to another, but its a start. I'm sharing it here
so that other people can begin to use it.
It just blats the import-able file out on standard output for now, and
it only copies from Commons, so it should be used in the following way:
$ php dupe-gadgets.php > import-this-file.xml
[ Go to Special:Import on your wiki and import. ]
I hope that it helps someone!
--
Mark A. Hershberger
Bugmeister
Wikimedia Foundation
mah(a)wikimedia.org
Hi,
We've created one page called MediaWiki:CentralCSS.css . This page is supposed to "call" css subpages.
Then we've created 5 css subpages, called :
* MediaWiki:Reset.css
* MediaWiki:Layout.css
* MediaWiki:Colors.css
* MediaWiki:Typo.css
* MediaWiki:Special.css
Now, we'd like the 5 css subpages been "called" into the central one.
What should we write into the MediaWiki:CentralCSS.css in order to get the css rules writen in subpages, working across the central css page ?
something like : [[MediaWiki:Reset.css]] ? putting name of pages into brackets [[ xxx ]] ?
Thanks a lot for your help
AC
> Thanks for your replies, I realize this is a faulty plugin right now for
> following reasons
Neat idea, though, for the reasons you cite. I'm on a slow connection, and sometimes a CAPTCHA (off-site) holds up the entire page.
----------------
The evolution of the human race will not be accomplished in the ten thousand years of tame animals, but in the million years of wild animals, because man is and will always be a wild animal. -- Charles Galton Darwin
:::: Jan Steinman, EcoReality Co-op ::::