At the architecture summit yesterday we had a conversation about the TitleValue proposal and the vast majority of folks thought it was a great start. Something like 10% of us thought the patch _might_ be a start down the path to Javaify MediaWiki. I was one of the 10%.
We resolved to talk more about the commit before merging it because of the objections of our minority. I felt somewhat vindicated. I slept on it. Now I don't think we made the right choice. I think more discussion is a waste of time and we should just keep moving and try to catch the Javaification if it starts creeping in.
The TitleValue proposal is an improvement over what we have now so I figure we should just do it. Is that ok?
In the mean time, mostly to humor me, does anyone want to start a list on wiki of some of the Javaification things they are scared of? I promise to contribute some paranoid ramblings which we can debate on the wiki or mailing list.
Thanks,
Nik
I would like to have an open IRC meeting for RFC review, on Tuesday 24
September at 22:00 UTC (S.F. 3pm).
We will work through a few old, neglected RFCs, and maybe consider a
few new ones, depending on the interests of those present.
The IRC channel will be #mediawiki-rfc.
-- Tim Starling
On Mon, Jan 13, 2014 at 9:10 AM, Chris Steipp <csteipp(a)wikimedia.org> wrote:
>> To satisfy Applebaum's request, there needs to be a mechanism whereby
>> someone can edit even if *all of their communications with Wikipedia,
>> including the initial contact* are coming over Tor or equivalent.
>> Blinded, costly-to-create handles (minted by Wikipedia itself) are one
>> possible way to achieve that; if there are concrete reasons why that
>> will not work for Wikipedia, the people designing these schemes would
>> like to know about them.
> This should be possible, according to https://meta.wikimedia.org/wiki/NOP,
> which Nemo also posted. The user sends an email to the stewards (using tor
> to access email service of their choice). Account is created, and user can
> edit Wikimedia wikis. Or is there still a step that is missing?
I tested the existing process by creating a new riseup.net email
account via Tor, then requesting account creation and a global
exemption via stewards(a)wikimedia.org. My account creation request was
granted, but for exemption purposes, I was requested to go through the
process for any specific wiki I want to edit. In fact, the account was
created on Meta, but not exempted there.
The reason I gave is as follows:
"My reason for editing through Tor is that I would like to write about
sensitive issues (e.g. government surveillance practices) and prefer not
to be identified when doing so. I have some prior editing experience, but
would rather not disclose further information about it to avoid any
correlation of identities."
This seems like a valid reason for a global exemption to me, so I'm
not sure the current global policy is sufficient.
Erik
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
The title pretty much say what I need
1) Retrieve the page - page must not be changed starts NOW
2) Do something what requires user input, possibly may last few minutes
3) Save the page ONLY if it wasn't changed, if it was, go back to step 1
this all needs to be done using API, I thought that edit token would
help me here, so that I would fetch the token at step 1 and edit using
it at step 3, hoping it expire if someone edit the page meanwhile. But
this doesn't seem to work according to documentation, because edit
token is only changed when user logout.
Is there any super-safe and proper method to do this? Preferably
something more reliable than just storing the timestamp and comparing
it (in theory someone could edit the page even in short time when
timestamp is compared). I need some super-safe lock that prevent all
possible race conditions here.
Hi, I am thinking of implementing a
#CATQUERY <query>
magic keyword for the category pages.
When this keyword is present, the category page would execute a query
against the search backend instead of normal category behavior and show
result as if those pages were actually marked with this category.
For example, this would allow Greek Philosophers category page to be
quickly redefined as
a cross-section of greeks & philosophers categories:
#CATQUERY incategory:Greek incategory:Philosopher
Obviously the community will be able to define much more elaborate queries,
including the ordering (will be supported by the new search backend)
I’m pretty sure that WMF is using Redis for the MediaWiki job queue. I see some sparse documentation on setting it up. I already have redis on my machines and would like to move to this to make life easier on my database server, but I’m wondering if this is fully baked and ready for use. Are there folks outside of WMF using Redis for their job queue?
--
Jamie Thingelstad
jamie(a)thingelstad.com
Hello,
I would like to announce the release of MediaWiki Language Extension
Bundle 2014.01. This bundle is compatible with MediaWiki 1.22.2 and
MediaWiki 1.21.5 releases.
* Download: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2014.01.tar…
* sha256sum: 2dc673ba0bbc43a3d69237c15600171e85d3c56d9ff520e5bdb3eda0f2fdc74a
Quick links:
* Installation instructions are at: https://www.mediawiki.org/wiki/MLEB
* Announcements of new releases will be posted to a mailing list:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n
* Report bugs to: https://bugzilla.wikimedia.org
* Talk with us at: #mediawiki-i18n @ Freenode
Release notes for each extension are below.
-- Kartik Mistry
== Babel, CLDR, CleanChanges and LocalisationUpdate ==
* Only localisation updates.
== Translate ==
=== Noteworthy changes ===
* Bug 45695: Added plural support for Android file format.
* Bug 46831: Fixed HTML validation error which caused broken layout in
especially in the Monobook skin when language is blacklisted.
* Bug 59199: Regression in the previous MLEB release: Message groups
without changes were listed on Special:ManageMessageGroups.
* Bug 59241: MediaWiki plural syntax checker no longer warns about
false positives.
* Bug 60128: Fixed statsbar for subgroups in the message group
selector for correct statistics.
* Bug 60198: Preserve whitespace in review mode. In review mode,
whitespace was not preserved and new lines were being displayed as
single spaces, which was messing up the messages.
* Fixed a regression caused by Alt shortcuts introduced in the
previous MLEB release: Can again access special characters with AltGr.
* Translation editor now reacts better to page scrolling and resizing.
* Set directory and language of insertables to the source messages' values.
* Special:SupportedLanguages is now faster.
* Translate can be installed via Composer now.
== UniversalLanguageSelector ==
=== Noteworthy changes ===
* Bug 59175: When clicking a regions in the map in ULS, scroll only
the list of languages and not the entire page.
* Bug 59239: Fixed an alignment issue of ULS personal toolbar trigger.
* Bug 59958: Fixed an issue where web fonts were sometimes loaded for
elements that use the Autonym font.
=== Fonts ===
* Added new font RailwaysSans.
* Updated AbyssinicaSIL font to latest upstream (1.500) version.
* Fix name of Scheherazade to properly target locally installed font on system.
--
Kartik Mistry/કાર્તિક મિસ્ત્રી | IRC: kart_
{kartikm, 0x1f1f}.wordpress.com
Hi guys!
I've installed MWSearch and Lucene Search extensions but I can see that the
search engine doesn't understand the morphology of Russian (doesn't
recognize word forms). How can I turn the morphological analyzer on? How
it's done in Russian Wikipedia?
Cheers,
-----
Yury Katkov, WikiVote
