Today, Kaldari wanted to have translate enabled on foundationwiki so that
Special:MyLanguage was available, but that would fall afoul of bug:44871
[1]. This is not a unique request, fundraising also has some use for
MyLanguage features on wikis that don't have (and wont have) translate.
Are there any concerns with separating out that special page into it's own
extension? The one that immediately jumps to mind is how the i18n team
bundles translate.
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=44871
~Matt Walker
Wikimedia Foundation
Fundraising Technology Team
Hallo,
MediaWiki has change tags, which are used for a bunch of things - mobile
edits, visualeditor, etc.
The page that describes the relevant database table is
https://www.mediawiki.org/wiki/Change_tag .
The table has a column called ct_params, described on that page as
"Parameters for the tag, presently unused."
Why is it unused? Is there a reason not to start using it?
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
Why is it still, now in 2014, so hard to find images?
We have categories and descriptions, but we also know
they don't describe all that we want to find in an
image. If I need an image with a bicycle and some red
flowers, I can only go to the category:bicycles and
hope that I'm lucky when browsing through the first
700 images there. Most likely, the category will be
subdivided by country or in some other useless way
that will make my search harder.
Where is science? Google was created in 1998, based
on its Pagerank algorithm for web pages filled with
words and links. That was 14 years ago. But what
algorithms are there for finding images?
--
Lars Aronsson (lars(a)aronsson.se)
Aronsson Datateknik - http://aronsson.se
We have several internal wikis that we maintain. We write extensions to these wikis. We are trying to convince management to upgrade our mediaWiki version to 1.23.x. At the same time we will upgrade our PHP version from 5.2.8 to 5.4.x. We have kept our PHP version to 5.2 because of the old mediaWiki version.
We are currently at mediaWiki 1.15.3. As developers we know that we are way overdue on upgrading, but no one has ever wanted to pay for it.
Some of the obvious things are:
1. Both the Media wiki version and the php version are no longer supported.
2. We do not have access to the most recent extensions.
3. Limited documentation for the old versions.
4. General security vulnerabilities. - I would love to have any specifics here.
Does anyone have any other points that I could add that would make management say yes? We have been reading about performance boasts. Any specifics?
I would also take any links that may be helpful.
Thanks,
Mary
So from what I can see Flow pretty much does everything LiquidThreads
does. Usually better (permalinks with LiquidThreads are one thing that
completely bugs me - they don't always take me to the correct place)
As I understand it there is a migration script that turns LiquidThread
pages to Flow boards.
It seems silly maintaining 2 pieces of software that do the same thing
on Wikimedia clusters.
So I want to know:
* What are the blockers for doing this?
* Are there any use cases / killer features in LiquidThreads that are
not in Flow that need to be ported over?
Hi,
So from what I understand, there's now been an amendment to WMF's
terms of use to require disclosure of paid "contributions" [1]. Its a
little unclear how this applies to MediaWiki as a project, but a
literal reading of the policy makes it seem like MediaWiki is
included.
* MediaWiki is arguably a project of the Wikimedia foundation. The
foundation's website says as much [2]
*A commit/patchset certainly seems like a contribution.
Thus the new policy would require anyone submitting code to use to
declare who they work for. Personally this seems both unnecessary to
me, as well as unlikely to be followed. For example, I see no reason
why some person who uses our software should have to declare who they
work for when they upstream a bug fix, etc.
I would suggest we follow commons' lead [3], and declare that we do
not have disclosure requirements for people giving us code.
--bawolff
[1] https://wikimediafoundation.org/w/index.php?title=Terms_of_Use&diff=0&oldid…
[2] https://wikimediafoundation.org/wiki/Our_projects
[3] https://commons.wikimedia.org/wiki/Commons:Requests_for_comment/Alternative…
Hello All,
I'm working on the Open-Access Signalling Project[1], which aims to signal
and badge when a reference in Wikipedia is Open Access source. I'm writing
the bot at the moment to do this, and I'm encountering a question - how do
I keep track of the values of the template {{Cite doi | doi=value}}, in as
close to real-time as possible?
The most efficient approach I can come up with is to query the SQL servers
on Labs in constant loop, returning the results of "What transcludes {{Cite
doi}}" and seeing if the last_edited timestamp is newer than previous? If
the last_edit is newer, then get the content of the page and see if the
{{Cite_doi}} value has changed, checking against a local database.
This seems horribly inefficient still. Is there a hook to know when a
template on a page has been edited, rather than having to check every time
the page has been edited?
Thanks in advance,
Max Klein
‽ http://notconfusing.com/
[1]
https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Open_Access/Signalling_…
Jon,
>From the looks of it, you may be invoking the tests from your host OS, not
the Vagrant-managed VM. Trying logging in to the VM using `vagrant ssh` and
executing the tests from there.
master x ~/git/vagrant $ vagrant ssh
...
vagrant@mediawiki-vagrant:~$ cd /vagrant/mediawiki/tests/phpunit
vagrant@mediawiki-vagrant:/vagrant/mediawiki/tests/phpunit$ php
phpunit.php
If you still have problems with it, feel free to come grab me and we can
troubleshoot it further.
On a related note, I'll be working on improving the mediawiki-vagrant
browser tests setup for MobileFrontend in the coming weeks. It'd be great
to have you, or someone else on the mobile team, vet the improvements.
Cheers,
Dan
--
Dan Duvall
Automation Engineer
Wikimedia Foundation <http://wikimediafoundation.org>