Hey,
I've asked this question about 2 years ago also, but couldn't find an
extension to help me.
I want to add a meter (eg. thermometer that was on Wikipedia for the
funds they needed).
My idea is to set a goal of 1000 articles by the end of the year,
currently I have 241 articles. So the meter will show 241/1000 in text
and graphics on every page of the website./or just the main page.
How will I be able to create such a meter/graphic?
Any help will be appreciated.
Thank you.
Regards,
Sarel
(South Africa)
Search does not work on my new wiki. I'm using version 1.15.2 with
SQLite. (I'm not talking about 3-letter searches as mentioned in the faq.
*No* search returns any page.)
Can I turn on a log to verify new pages are being indexed? How? Which
tables hold the index data?
If indexing isn't being done, how might I find out why not, and what
should I do to turn it on?
Reading the documentation and archives, it appears search is a continuing
source of difficulty up until 1.11, and that MySQL is the "expected"
backend. I'm using 1.15 and SQLite.
Many thanks for any advice.
--jkl
Hi all!
This is a quick reminder that registration for the Wikimedia Developers'
Workshop (in Berlin, April 14-16) will end on Sunday, March 21. Most places are
already take, but we have room for 16 more people to attend.
So, if you want to come, sign up now at <http://www.amiando.com/WMCON10DEV.html>!
More information about the workshop is available at <http://tinyurl.com/wmdev10>.
-- Daniel Kinzler
Good day everybody,
I'm using mediawiki 1.15.1 with german localisation.
$wgLanguageCode = "de-formal";
Well, this works messages, navigation, special pages and so on are german. But
after an update from 1.14 to 1.15.1 all the words are written with small
letters. Normally each word should begin with a capital letter. As you can see
at the german wikipedia, left and top navigation such as site <-> Hauptseite
or edit <-> Bearbeiten are with capitals in front.
Does anyone know if there is another variable wich must be set?
Hi all,
This is the background. A year ago we hired a person to
update and add some improvements we needed, with an estimated
time of 8 weeks. After months of delays and a lot of problems,
we've fired him. Unfortunately, I'm afraid the database has
been damaged or not properly set up.
Now, two questions--
1) In the short term, I'd like to fix an issue with searches.
The site is in Spanish but it's unable to find words with
diacriticals in the article body (in the title they are found).
I've rebuilt the search index, with no luck. Fortunately, I
had access to old dumps and I've noticed a difference --
formerly tables were like
CREATE TABLE `wl_archive` (
`ar_namespace` int(11) NOT NULL default '0',
`ar_title` varchar(255) character set latin1 collate latin1_bin NOT
NULL default '',
[...]
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
and now they are like
SET @saved_cs_client = @@character_set_client;
SET character_set_client = utf8;
CREATE TABLE `wl_archive` (
`ar_namespace` int(11) NOT NULL default '0',
`ar_title` varchar(255) character set latin1 collate latin1_bin NOT
NULL default '',
[...]
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
SET character_set_client = @saved_cs_client;
2) In the medium term, and with the background above, which
is the best approach to have a "correct" database and system
again.
Thanx
Javier
--------------------------------
www.wikilengua.orgwww.tex-tipografia.com
On many online systems (email interfaces, forums, social networks, CMS's), URLs with brackets and apostrophes break very often. For example:
http://en.wikipedia.org/wiki/Stayin'_Alive
If this URL is posted to Facebook, Facebook will render the URL link as:
http://en.wikipedia.org/wiki/Stayin
Similarly links with brackets will break on different systems. For example:
http://en.wikipedia.org/wiki/Andrew_Roberts_(historian)
This doesnt break on Facebook but it breaks in this very Yahoo email interface that I'm using right now (their HTML editor) and it renders the link as:
http://en.wikipedia.org/wiki/Andrew_Roberts_(historian
So its a very common problem and because there are so many page titles with these characters, there are likely thousands of links that break every day from Wikipedia, other wikis and other websites.
We know ofcourse its not the fault of Mediawiki because this is a URL-related problem that falls under the responsibility of the people who program the interfaces that produce the links, but - what can be done about this?
A few times I've contacted the systems to let them know they should take care of links with apostrophes and brackets but there's just too many systems and sadly, they dont follow any kinds of standards when it comes to URL link rendering, and they do their own thing.
Erik
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The first beta release of the 1.16 branch is now available for
download. Please try it and tell us if it works for you. This beta
release is not recommended for use in a production environment.
Selected changes since MediaWiki 1.15 that may be of interest:
* Watchlists now have RSS/Atom feeds. RSS feeds generally are now
hidden, since Atom is a better protocol and is supported by virtually
all clients.
* It's now possible to block users from sending email via
Special:Emailuser.
* The maintenance script system was overhauled. Most maintenance
scripts now have a useful help page when you run them with --help.
* AdminSettings.php is no longer required in order to run maintenance
scripts. You can just set $wgDBadminuser and $wgDBadminpassword in
your LocalSettings.php instead.
* The preferences system was overhauled. Preferences are stored in a
more compact format. Changes to site default preferences will
automatically affect all users who have not chosen a different preference.
* Support for SQLite was improved. Some broken features were fixed,
and it now has an efficient full-text search.
* The user groups ACL system was improved by allowing rights to be
revoked, instead of just granted.
* A new localisation caching system was introduced, which will make
MediaWiki faster for almost everyone, especially when lots of
extensions are enabled.
By default, this new system makes a lot of database queries. If your
database is particularly slow, or if your system administrator limits
your query count, or if you want to squeeze as much performance as
possible out of Mediawiki, set $wgCacheDirectory to a writable path on
the local filesystem. Make sure you have the DBA extension for PHP
installed, this will improve performance further.
Full release notes:
http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_16_0beta1/phase3/RELEA…
**********************************************************************
Download:
http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.0beta1.tar.gz
GPG signatures:
http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.0beta1.tar.gz.s…
Public keys:
https://secure.wikimedia.org/keys.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkua4+gACgkQgkA+Wfn4zXmEegCfaZ153qv8zNiQk18JNwiTfi3w
NZcAni7Yf8v/lQcctKGya4JH4ow4hAFb
=JK00
-----END PGP SIGNATURE-----
I'm experimenting with implementing a wiki family with MW 1.15.2 and have seen some bizarre behavior when I change domains. Anybody have an explanation?
I set up 3 hostnames, en.mywiki.com, de.mywiki.com, and fr.mywiki.com, on the same server, thanks to DNS and Apache. They all point to the same physical MediaWiki code tree and database, but in LocalSettings.php, I override $wgLanguageCode differently (to 'en', 'de', and 'fr') based on the hostname. Simple so far.
Here's the strange part. When I visit en.mywiki.com and change MediaWiki:Common.css (say, make the body background color = pink), then refresh the browser, the changes show up as expected. But when I browse to fr.mywiki.com and de.mywiki.com, the CSS does NOT take effect, even though they use the SAME MediaWiki:Common.css page in the database. I can view MediaWiki:Common.css under all three hosts, and it displays identically for all three URLs (I see "background-color=pink"). But the CSS never takes effect for the fr and de domains.
It gets stranger. If I now edit MediaWiki:Common.css on fr.mywiki.com - say, change the body background color from pink to green - then fr.mywiki.com becomes green, but en.mywiki.com REMAINS PINK! And de.mywiki.com is still unchanged from the default.
Browser refreshes do nothing. Browser cache-clearing does nothing. Trying in different browsers makes no difference.
Any ideas??
Thanks,
Dan
I've been using perl (Mediawiki::API) to work with the API, since
perl is my preferred medium. However, it will not work with the
Flagged Revs actions (there is an explicitly limited list of actions
that it will work with).
Before I go through all of them, does anyone have a recommendation for
which client module could do this (ruby, python, php, js -- cannot
use .NET or Java here)?
--
MK <halfcountplus(a)intergate.com>