Re: [Wikitech-l] [Wikitech-ambassadors] [Translators-l] update: wikipedia.org portal

[Tisza Gergő]

On Sat, May 21, 2016 at 6:58 PM, Federico Leva (Nemo) 
wrote:

> Purodha Blissenbach, 21/05/2016 14:13:
>
>> On the long run, I think, these portals and their texts should
>> be translatable. Browser settings determining the target language.
>> Looking forward to have them on translatewiki.net !
>>
>
> Adding English-only text to the Wikipedia portal is unacceptable. Special
> powers on a Wikimedia domain must not be used to contradict and impoverish
> the Wikimedia mission. The portal seize by a small WMF clique has shown its
> failure and should immediately be reversed, as the Meta-Wiki administrators
> have proven to be more competent.
>

Folks, the horse carcass is starting to stink. Time to stop, drop and back
away.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] MediaWiki handout material

[Tisza Gergő]

Hi all,

I am a member of Wikimedia Hungary, which will have a stand at the Hungarian 
Free Software Conference this weekend. I thought that would be a good 
oppurtinity to raise awareness for MediaWiki. Do you know of leaflets or other 
handout materials about SMW which I could translate to help with that? Or any 
source material to compose something similar from? Testimonials, comparisons, 
statistics, feature sets etc.

thanks
Gergő


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] facebook like box in mediawiki

[Tisza Gergő]

Max Semenik maxsem.wiki at gmail.com writes:

 
 On 19.04.2011, 10:24 K. wrote:
 
  I haven't quite looked back to the discussions, but couldn't you have
  the extension load a local icon/image for the button and then manually
  construct the url to be clicked in the same style that the wikinews
  does their template?
 
 Then it would violate the free content doctrine, unles you manage to
 convince FB to release their button images under a free license :P

Actually it would be a plain copyright violation (and quite possibly some sort 
of trademark violation too); Facebook terms of use do not allow modifying the 
looks or behavior of the Like button in any way.

Also worth noting that chapters participating in the fundraiser and receiving 
traffic from the fundraiser banners must have a privacy policy compatible with 
that of the WMF, which probably means no Like buttons (for the duration of the 
fundraiser, at least).

Other than that, though, I don't think arbitrary cultural standards should be 
imposed on self-hosted chapter homepages. It is their job to decide whether 
their readers would be happy about some data about their browsing being shared 
with Facebook, and they can probably do a better job about it than a random 
group of wikitech-l posters most of whom don't even speak the language.

I also do not see why being hosted by WMF would make any difference. Users 
might 
have a reasonable expectation to be protected by the WMF privacy policy while 
they are on a *.wikimedia.org domain, but if the site is hosted under some 
other 
domain name, there is no reason to enforce WMF policy.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Cross wiki script importing

[Tisza Gergő]

Raimond Spekking raimond.spekking at gmail.com writes:

 Try something like
 

importScriptURI('http://ml.wikipedia.org/w/index.php?title=Mediawiki:rules.js‎action=rawctype=text/javascript');

That will break HTTPS security though. I use this script on my home wiki:

function importScriptIw(page, lang, project) {
  if (lang in ['commons', 'meta']) {
project = 'wikimedia';
  } else { 
project = project || 'wikipedia';
  }
  if (window.location.protocol == 'https:') {
var scriptPath = 'https://secure.wikimedia.org/' + project + '/' + lang +
'/w/index.php';
  } else {
var scriptPath = 'http://' + lang + '.' + project + '.org/w/index.php';
  }
  var uri = scriptPath + (?title= + encodeURIComponent(page.replace(/ /g,
_)).replace(/%2F/gi, /).replace(/%3A/gi, :) +
action=rawctype=text/javascript); 
  return importScriptURI(uri);
}

importScriptIw('Mediawiki:rules.js‎', 'ml');



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Firesheep

[Tisza Gergő]

Conrad Irwin conrad.irwin at gmail.com writes:

 There is no real massive load caused by https at runtime.  There is however
 a significant chink of developer and sysadmin time needed to implement this
 and make it work.

Secure login in itself shouldn't require reconfiguration of the SSL
architecture, though. The login form could simply redirect to a page on the
secure server, and use the image cookie method already in use for global logins.
That would take care of password stealing without requiring extensive
configuration or development efforts, and cookie stealing in itself is not that
much of an issue: only admin sessions are worth stealing, and the chances of an
attacker happening to be next to an admin on open wifi are very small. (Sure, it
would be better to provide a decent https interface and require them to use it,
because script injection is not a good thing, but apparently it won't happen
anytime soon, and we shouldn't hold back on implementing secure login because of
that.)


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Parallel computing project

[Tisza Gergő]

Aryeh Gregor Simetrical+wikilist at gmail.com writes:

 To clarify, the subject needs to 1) be reasonably doable in a short
 timeframe, 2) not build on top of something that's already too
 optimized.  It should probably either be a new project; or an effort
 to parallelize something that already exists, isn't parallel yet, and
 isn't too complicated.  So far I have the password-cracking thing,
 maybe dbzip2, and maybe some unspecified thing involving dumps.

Some PageRank-like metric to approximate Wikipedia article importance/quality?
Parallelizing eigenvalue calculations has a rich literature.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Convention for logged vs not-logged page requests

[Tisza Gergő]

Rob Lanphier robla at wikimedia.org writes:

 In diving into a problem with logging[1], we discovered that we were
 unintentionally treating several special page accesses (in this case,
 containing included Javascript) as normal pageviews, thus throwing our
 pageview statistics way off.  The proposed solution involves changing
 the way we access those Javascript requests from this form:
 http://en.wikipedia.org/wiki/Special:BannerController
 
 ...to this form:
 http://en.wikipedia.org/w/index.php?title=Special:BannerController

The problem with that is that most of the time, URLs like that *should* be
logged - they are simply the result of someone using a special page. For
example, search page loads (about 3% of all page loads!) go completely under the
radar this way, and while some wikipedias use hacks like [1] to avoid that, it
really isn't an ideal situation. Also, page edits and other actions are not
logged, nor page loads for old versions of pages, or for pages linked from
recentchanges, or unstable versions where FlaggedRevs are enabled.


[1]
http://de.wiktionary.org/w/index.php?title=MediaWiki:If-search.jsaction=rawctype=text/css


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] processing irc://irc.wikimedia.org/en.wikipedia

[Tisza Gergő]

Ed Summers ehs at pobox.com writes:

 Thanks for the help folks. If anyone is curious, here's a little
 python script I wrote that prints out the (parsed) edit stream:
 
 http://gist.github.com/628199

A year ago or so, some of us at #wikipedia-hu wrote a bot script that can react
to events on the live RC channel, maybe you find it useful:
http://pastebin.com/yvkdZchQ


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] wiki(m|p)edia.org on IE8 compatibi lity blacklist

[Tisza Gergő]

wikimedia.org, wikipedia.org, wikipedia.de and wiktionary.org are on the IE8
compatibility blacklist again (you can check by opening
res://iecompat.dll/iecompatdata.xml in IE8 or at
http://ie8blacklist.appspot.com/ ), which means that IE8 renders Wikipedia pages
just as IE7 would. I see no obvious difference when switching into IE8 standards
mode. Does someone know the reason for the blacklisting? If not, could someone
from the foundation ask them to remove these sites from the list? (Information
on removal requests can be found at the end of this article:
http://msdn.microsoft.com/en-us/library/dd567845%28VS.85%29.aspx )


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] wiki(m|p)edia.org on IE8 compatibi lity blacklist

[Tisza Gergő]

Aryeh Gregor Simetrical+wikilist at gmail.com writes:

 W3C validation isn't relevant here.  Sites get blacklisted by
 Microsoft if they don't work well in IE8, for any reason.  Invalid
 markup isn't a major issue for us, but we might be triggering IE8 bugs
 or misfeatures for other reasons.

Also, their problem is not necessarily with the main page. Microsoft blacklists
the whole second-level domain if they find a lot of incompatible pages (whatever
that means) on it.



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Template collapsing in Citron - default text?

[Tisza Gergő]

The soon-to-come third version of the usability extension, Citron, will be able
to collapse templates in the edit window:
http://usability.wikimedia.org/w/index.php?title=File:Updated_Citron_templates.pdfpage=1

The problem with this approach is that sometimes collapsing is harmful to the
readability of the wikitext. For example, huwiki has a template which looks like
this: Water is generally thought to be wet, {{citation needed|text=though some
argue it is actually dry}}. That is, it can be used to select a specific part
of the text and mark it as problematic. There are many similar templates which
annotate a section of the text without breaking its flow; of you collapse the
template, the text becomes much harder to read.

The reason I'm asking about this is that we're just about to reorganize some
template parameter naming conventions, and would like to consider future
compatibility with Citron, and the only solution to the above problem I can
think of is to have a whitelist of template parameter names whose values will be
visible even in a collapsed state. (Being able to define such parameters with
per-template settings would be more flexible, but I suppose it is very expensive
to do so.) So, is there a chance Citron will have such a feature in the future
and there is value in giving all such parameters a common, distinctive,
non-numeric name?


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Template collapsing in Citron - default text?

[Tisza Gergő]

Roan Kattouw roan.kattouw at gmail.com writes:

 We've also been thinking about integrating these features with
 template metadata. We were mostly thinking about things like parameter
 types and descriptions, but collapsibility could be another attribute
 of a template.

Ideally it should be a per-parameter attribute; for example, {{citation
needed|text=2+2=5|from=January 2009}} should be displayed as [citation
needed]2+2=5] for maximum readability.

The problem with the metadata approach is that while usually you can get away
with loading it in the background when the user clicks on the collapsed icon,
collapsibility metadata must be available for all templates as soon as the page
is loaded. That would mean dozens, sometimes hundreds of extra queries for a
single edit screen, or some sort of template metadata cache.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] serious questions about UsabilityInitiativ e going live

[Tisza Gergő]

Bence Damokos bdamokos at gmail.com writes:

 There is also a spreadsheet at https://spreadsheets.google.com
 /ccc?key=0Aikdcg5HdSKbdDVMM2l2SGM2dUtBU25MLUtTMFEwMFEhl=hu
 
 I wonder if the user comments and survey results for the Hungarian Wikipedia
 are available anywhere? Hungarian is not included in the nice tables I found
 on usability wiki, yet the retention rate is just below 60%.

Data until Oct. 29 is apparently available at 
http://toolserver.org/~catrope/survey/


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] serious questions about UsabilityInitiativ e going live

[Tisza Gergő]

Roan Kattouw roan.kattouw at gmail.com writes:

 That's deliberate, the TOC requires the iframe, which was disabled
 because of copy-paste issues. We're also not enabling NTOC as a
 default feature, so this is irrelevant.

Does that mean the iframe-based editor will not be enabled? It sounds much less
scary that way :) It still has a number of small but annoying bugs - the edit
box scrolling away on copy/paste, unexpected blurs, unresponsiveness when
loading, etc.

The Vector skin itself, on the other hand, seems mature - it will be cool to
have it as default. (Does that mean that users who have never touched their skin
settings will automatically get it too, or only those who register in the 
future?)


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] ? earlier versions of user access levels + permissions

[Tisza Gergő]

Q overlordq at gmail.com writes:

 If you're referring to what rights a group is assigned, then no, there
 isn't a historical record. The only way, afaik, is possibly digging
 through the wikitech admin log and bugzilla and trying to piece it together.

The default user group rights are set in includes/DefaultSettings.php (or the
relevant extensions) and their history can be recreated from SVN. Most default
associations were never overridden (though those are the less interesting ones,
I suppose). Important changes can usually be found in Bugzilla, under the
Wikimedia/Site requests component. You could also try to check the page history
of http://en.wikipedia.org/wiki/Wikipedia:User_access_levels .


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Commons new file feed

[Tisza Gergő]

Hi,

is there a MediaWiki feature or external tool to get a live feed of Commons file
uploads? (By live I mean something that can be used to show a realtime slideshow
of new images. I vaguely remember someone saying that the WMF office has a
screen with such a slideshow.)

If there is no such thing, what would be the best starting point to write one?
#commons.wikime...@irc.wikimedia.org?

thanks
Gergő


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki 1.16.0beta1 now available

[Tisza Gergő]

Tim Starling tstarling at wikimedia.org writes:

 * 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.

Could this be switched on on WMF wikis? Currently if you click on the feed icon,
you will see Wikipedia RSS feed and Wikipedia Atom feed, and I doubt more
than a few percent of our visitors understand those.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] modernizing mediawiki

[Tisza Gergő]

Aryeh Gregor Simetrical+wikilist at gmail.com writes:

 2) Some people really want to see the software succeed for
 non-financial reasons, so they're willing to put in extra effort to
 make it easier to use even if it doesn't directly benefit them.
...
 (2) hasn't happened because most
 of us care mainly about Wikipedia or the wikis we administer, and
 aren't overly concerned with third parties who aren't savvy enough to
 use a command line.

Which is too bad; it would be very useful for Wikimedia's mission if MediaWiki
was more widespread and more people would be more comfortable using it. It would
be especially useful if it would be widespread in educational and academic
circles (though it already seems to be the wiki engine of choice there) as those
are key target demographics for Wikipedia; the foundation could spend some
effort to analyze what are the greatest shortcomings of MediaWiki in that area.
(One-click install and reorganizable widgets probably wouldn't get on that list,
though.)


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] modernizing mediawiki

[Tisza Gergő]

Chad innocentkiller at gmail.com writes:

  I have no idea if there's a nice Windows package friendly enough for
  the low-to-medium-tier NT admins (those who watch progress bars for a
  living), but that would be nice. They're not going to get away from
  the command line and text configuration files, though.
 
 
 XAMPP. It takes a whopping 5 minutes to download and install. Gives
 you Apache/mySQL/PHP all ready to go at C:\xampp. It really cannot
 get any easier than this. If you can't install this, I wouldn't even trust
 you to run my WordPress.

There is also a single-file installer for MediaWiki + AMP stack (
http://bitnami.org/stack/mediawiki ) for people who really can't do anything
more difficult than clicking OK buttons.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] modernizing mediawiki

[Tisza Gergő]

Ryan Lane rlane32 at gmail.com writes:

 I'd like to mention that from a security perspective, I like the fact
 that by default MediaWiki does not allow Wordpress style upgrades and
 code modifications. MediaWiki exploits may lead to vandalism, but
 Wordpress exploits generally lead to shell or root access, and
 compromise of all of your other applications.

While this is certainly true for updates and PHP-enabled skin files, a web-based
configuration panel is actually much more secure than editing a PHP-based
settings file through FTP. There is a multitude of malware out there which can
steal FTP passwords by infecting your computer, or your router, or any nearby
computer if you use unsecured wifi access. (Sure, you could use SFTP or
something equivalent, but how many people actually do? And how many webhosts
provide it?) The most common stuff such as allowing uploads or enabling
extensions should be accessible through a GUI for both usability and security
reasons.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Update on single-revision deletion

[Tisza Gergő]

On Thu, Dec 10, 2009 at 17:52 PM, Andrew Garrett agarrett at wikimedia.org
wrote:

 Just a note to say that I didn't go ahead with my
 planned implementation of revision suppression
 for all administrators, because Aaron said that he
 would rather that I wait until bug 20928. Once that
 is fixed, I will again look into deploying single-revision
 deletion for administrators.
 
 https://bugzilla.wikimedia.org/show_bug.cgi?id=20928

Are there still plans for going forward with this, and if yes, what is the
status of it? Bug 20928 is marked as fixed and the fix passed code review[1];
also it seems revision deletion is already enabled on pl[2] and he[3] so it must
be working reasonably well. On the other hand bug 21279 is still open[4] and it
sounds serious.

If the concerns in bug 21279 are not valid any more, it would be really nice if
revision deletion could be enabled at least on the wikis which specifically
asked for it (ja[5], de[6], simple[7], hu[8], en[9]).

[1] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/59949
[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=20331
[3] https://bugzilla.wikimedia.org/show_bug.cgi?id=20926
[4] https://bugzilla.wikimedia.org/show_bug.cgi?id=21279
[5] https://bugzilla.wikimedia.org/show_bug.cgi?id=7126
[6] https://bugzilla.wikimedia.org/show_bug.cgi?id=19697
[7] https://bugzilla.wikimedia.org/show_bug.cgi?id=19819
[8] https://bugzilla.wikimedia.org/show_bug.cgi?id=20947
[9] https://bugzilla.wikimedia.org/show_bug.cgi?id=21165


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tracker and PM tool part2: Redmine

[Tisza Gergő]

Priyanka Dhanda pdhanda at wikimedia.org writes:

 The Bugzilla users were migrated, but you will have to use the Lost 
 Password link to reset your password: 
 http://project2.wikimedia.org:3000/account/lost_password

For me that results in a Lastname is invalid error message; apparently it
can't handle non-ISO-8859-1 characters (an U+0151 in my case).


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Tisza Gergő]

Nikola Smolenski smolensk at eunet.rs writes:

 What I am going to say is going to be the worst heresy, but could this 
 problem be solved by gradually migrating to a new wiki markup, for 
 example **bold** and //italic//? This markup is more logical and easier 
 to remember, more used outside of MediaWiki (unofficial email markup is 
 similar) and more easily visible than apostrophe markup, and I never 
 understood how the apostrophes came to be in the first place. The most 
 important for this discussion - it also has much less potential to 
 confuse the parser.

You avoid a lot of pain if the opening and closing markup is different. 
That is IMHO the other big problem besides reusing the same characters in ''/'''
and {{/{{{.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Wikitext vs. WYSIWYG (was: Proposal for editing template calls within pages)

[Tisza Gergő]

Aryeh Gregor Simetrical+wikilist at gmail.com writes:
 Wikitext is not easy to edit.

It is easy enough to edit for power users, who make the large majority of edits;
and way more comfortable than WYSIWYG. Wikis require a certain hacker mentality
- not in the technical sense, but a desire to understand things in depth. It
takes effort to learn the syntax, but once you did, it gives you freedom and
effectiveness, because you are actually in control of things (as opposed to rich
text editors which sometimes do something similar to what you intended, at other
times not even close, because they use some fucked-up internal representation
that you have no way of knowing or understanding). This might be a problem for
Wikia with its fanboi target demographic that has the attention span of a Naruto
episode, but Wikipedia is an encyclopedia, and writing a good encyclopedia
article requires hacker mentality in the first place, so whatever.

And then there is the ecosystem of bots, gadgets and other third-party tools
which is based on wikitext, and not only would moving away from wikitext a huge
maintenance burden, but again it would be replaced with something that is way
less intuitive and actually harder to use (simple text operations are somewhat
easier than fooling around with document trees).

So if you can do WYSIWYG on top of wikitext, cool (the learning curve is
certainly steep for new users, and that will only become worse as new features
are added). If you can do a sort of WYSIWYM with syntax highlighting,
context-sensitive help and wizards for the more inconvenient elements like
templates, that is even better, because it wouldn't create a gap between people
using WYSIWYG and wikitext, and would allow for a gradual learning experience.
But replacing wikitext with some sort of internal representation that is
unreadable for humans would be a huge mistake IMO.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] JS2 design (was Re: Working towards br anching MediaWiki 1.16)

[Tisza Gergő]

Tim Starling tstarling at wikimedia.org writes:

 * Unnecessary use of the global namespace. The jQuery style is nice,
 with local functions inside an anonymous closure:
 
 function () {
function setup() {
...
}
addOnloadHook( setup );
 }();

This would make it impossible to overwrite the function locally on a wiki, which
is done sometimes, either because it conflicts with some local script, or for
better localization (such as changing the sorting algorithm in the
sortable-table script to handle non-ASCII characters decently). You should
rather use a global MediaWiki object, that works just as well for clearing the
global namespace, and it leaves the functions accessible.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Speed of parsing messages (was: how to chang {{SITENAME}})

[Tisza Gergő]

Gerard Meijssen gerard.meijssen at gmail.com writes:
 The plural construct is used when it is not clear how many items will be
 available. Consequently there is not much to be done about it. Also the
 effect of plural is not the same for every languages. Welsh allows for six
 ways of indicating a multitude.

Some of them may be rephrased, and some localizations do not really need them at
all. Foe example, in Hungarian number noun constructs the noun is always
in singular, so we've been using {{PLURAL:$1|one|$1}} thingy because the
automated checks complain if they see no PLURAL, but on hu.wikipedia it could be
replaced with $1 thingy without trouble. (I'm not sure there are actually
frequently loading messages which have PLURAL, but it's worth checking.)


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] LanguageSelector on strategy wiki

[Tisza Gergő]

The LanguageSelector extension [1] can automatically set the interface
language based on browser settings, which is nowadays the norm for
every serious multilanguage web page. It is not used on WMF wikis,
because it would interfere with caching. The strategic planning wiki
[2] has, however, relatively low traffic, and probably much higher
logged-in to anon ratio than the rest of the sites. Any chance
LanguageSelector (or something equivalent, if it exists) could be used
there?

[1] http://www.mediawiki.org/wiki/Extension:LanguageSelector
[2] http://strategy.wikimedia.org/wiki/Main_Page

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] FlaggedRevs on Hungarian Wikipedia still not working

[Tisza Gergő]

The autoreview feature for FlaggedRevs does not work in the Hungarian
Wikipedia because of a configuration problem with a group name. This
causes a lot of extra work for the patrollers, and a lot of extra
waiting for everyone else for their edits to appear.

It has been about forty days since I filed a bug about this; in the
meantime, I asked twice for help on wikitech-l (not to mention the
several personal emails and IRC messages I and other Hungarian editors
sent). After my first wikitech-l mail, there was a short and
unsuccessful attempt to fix the problem without actually understanding
what we asked for; before and after, in those seven weeks, nothing
happened.

This is very disappointing. To fix the bug, one would need to replace
all occurrences of 'confirmed' with 'trusted' in the huwiki flagrev
config file - that takes about 20 seconds. If one wanted to be
thorough about it and move users from the old group to the new, one
would need to construct an appropriate SQL query - maybe 5 more
minutes. There are about a hundred patrollers on hu.wikipedia
(including admins). If we suppose they only have to work one extra
minute a day each (a very unrealistic lower estimation), that adds up
to about sixty hours. Which is about a thousand times twenty seconds.

Is staff time really a thousand times more valuable than volunteer
time, so that no one can be bothered to make this trivial fix, even if
many hours of other people's time could be spared? I'm aware it is
summer, and Wikimania is going on, and everyone has a lot on their
hands, but even so I can't believe none of the people with shell
access can find a minute to make the fix.

Letting the time of the most active community members go to waste like
this is not only very discouraging them, and not only does it
undermine their trust in the revision flagging system (which proved to
be a very valuable anti-vandalism tool, but it was always hard to get
enough people involved), it also creates a rift between WMF and the
local community. People perceive that the foundation does not respect
their volunteer work at all, and it is only quick when it is creating
problems (their previous contact with WMF was when someone shot down
the statistics script that ran with community consensus, without as
much as a question or comment), and not when it should be solving
them.

If you want to broaden participation and involve more people into
meta-projects, start with actually caring about issues like these. And
now please, please find someone to finally fix bug 19885.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] site requests for Hungarian Wikipedia

[Tisza Gergő]

Rob Halsell rhalsell at wikimedia.org writes:

 All outstanding requests in the original email for this thread have been
 addressed and processed to completion.

The urgent one (autoreview not working,
https://bugzilla.wikimedia.org/show_bug.cgi?id=19885 ) is still unsolved, with
no activity for days. Sorry for being obstinate about this, but it really is
important. It took a lot of effort to convince huwiki patrollers that flagged
revisions will be good for them and get them to use it regularly, and now it's
been a huge amount of extra work for them, for two weeks. They can't keep up
with the load for long, and I'm worried they will get fed up, and the current
technical failure will turn into a social failure, and that one is much harder
to fix.

 Now, I am nearly always in IRC, even when I am not at the keyboard.
 While it is not a permanent solution, everyone should feel free to PM me
 with any requests that seem to have been outstanding and ready for
 processing a bit too long.  I may not be able to get to them right that
 second, but I am trying my best!  =]

I contacted r...@freenode, but got no reply. I'm not sure it was you though,
since the user did not identify himself to nickserv, and was not on any
Wikimedia-related channel. (The hostmask was n=...@5ad4934d.bb.sky.com.)
If it was you, you should probably set your client to autoident so people can be
sure it is you they are talking to. If it wasn't, you can tell nickserv to guard
your nick more aggressively by /msg nickserv set enforce.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] site requests for Hungarian Wikipedia

[Tisza Gergő]

Since I have run out of ideas of where to nag devs with shell access
(bugzilla is completely ignored most of the time, and mail/irc didn't
have much effect either), I'll try here.
The following are all one-line configuration changes:

Bug 14716 – Grant noratelimit right to the editor group in the
Hungarian Wikipedia (open for over a year)
Bug 19109 – Enable AbuseFilter in Hungarian Wikipedia (open for two months)
Bug 19315 – Set $wgCategoryPrefixedDefaultSortkey=false on Hungarian
Wikipedia (open for one and half month)
Bug 19885 – Restore autoreview for confirmed usergroup on huwiki
(severity:major, open for 10 days)

It would be really nice if someone could finally take a look at these,
especially the last one which completely sabotages the use of FlagRev
on huwiki (and which resulted from careless sysadmin action in the
first place).

More generally, I think the procedure for responding to site requests
(if there is a procedure at all) needs fixing. My impression is that
some requests are resolved quickly, and the rest leave the range of
whatever method shell people use to monitor new requests, and are
never picked up again (much like recent changes patroling on the
wiki). Some sort of backlog of open site requests might help the
situation. (Again, these are one-liners that need neither much thought
nor much effort, nor are they terribly frequent - there were 3 site
requests alltogether this year for huwiki, which is a top20 wikipedia
- so I'm sure it's an attention problem, not a resource problem.)

convenience links:
https://bugzilla.wikimedia.org/show_bug.cgi?id=14716
https://bugzilla.wikimedia.org/show_bug.cgi?id=19109
https://bugzilla.wikimedia.org/show_bug.cgi?id=19315
https://bugzilla.wikimedia.org/show_bug.cgi?id=19885

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wiki at Home Extension

[Tisza Gergő]

Michael Dale mdale at wikimedia.org writes:

 * We are not Google. Google lost what like ~470 million~ last year on 
 youtube ...(and that's with $240 million in advertising) so total cost 
 of $711 million [1]

How much of that is related to transcoding, and how much to delivery? You seem
to be conflating the two issues. We cannot do much to cut delivery costs, save
for serving less movies to readers - distributed transcoding would actually
raise them. (Peer-to-peer video distribution sounds like a cool feature, but it
needs to be implemented by browser vendors, not Wikimedia.)


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wiki at Home Extension

[Tisza Gergő]

Steve Bennett stevagewp at gmail.com writes:

 Why are we suddenly concerned about someone sneaking obscenity onto a
 wiki? As if no one has ever snuck a rude picture onto a main page...

There is a slight difference between vandalism that shows up in recent changes
and one that leaves no trail at all except maybe in log files only accessible
for sysadmins.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Translate extension, jqery

[Tisza Gergő]

Glanthor glanthor at gmail.com writes:

 the another big question is that why don't include JQuery to load
 automatically with _every_ pages? Now at least two wikis load JQuery
 v1.3.2 from common.js (see
 http://zh.wikipedia.org/wiki/MediaWiki:Common.js,
 http://hu.wikipedia.org/wiki/MediaWiki:Common.js), the
 UsabilityInitiative extension use JQuery v1.3.2 with cookie and
 browser plugins, and the collection extension use JQuery v1.3.2. Three
 JQuery, two version. This is not god...

Collection uses 1.2.5. I suppose we are waiting for ScriptLoader to be ready,
but it would be really helpful if it would be included normally for the meantime
so that site admins can start rewriting site-wide scripts. It has a very small
footprint (20k minified and gzipped), it is unobtrusive (AFAIK 1.3 doesn't even
conflict with other jQuery versions) and cannot be loaded through importScript()
due to a bug in older Explorers, which leaves including it full in
MediaWiki:Common.js which is not a nice sight...


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Code updated

[Tisza Gergő]

Brian Brian.Mingus at colorado.edu writes:
 
 On Thu, Jun 18, 2009 at 1:59 AM, Tisza Gergő gtisza at gmail.com wrote:
 
  Brian Brian.Mingus at colorado.edu writes:
  
   And of course Special:Version code has changed since the last time I ran
   that code, meaning there is really no reliable way to know what version
   of MediaWiki Wikipedia is running anyway.
 
  You can get
  http://en.wikipedia.org/w/api.php?action=querymeta=siteinfoformat=xml
  and look for /\brev=(\d)/. A separate SVN branch for the version used
  on live Wikimedia wikis would be a great improvement, though.

 Yes - this would be fantastic. It just needs to be a cheap copy which is
 essentially zero overhead on WMFs part. A 'live' tag for example.

I tried to suggest that a few weeks ago, but couldn't create much interest:
http://www.nabble.com/Live-SVN-branch-td23636464.html

If done properly, it would be probably more difficult than a simple copy of a
certain version, but it would also be much more useful. For example, Tim updated
SpecialUserrights.php to r52116 just a few minutes ago to fix a bug which
stopped it from working, but you wouldn't know that from looking at
Special:Version. 


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Live SVN branch

[Tisza Gergő]

The latest stable MediaWiki branch is usually 3-6 months behind the one used on
the Wikimedia sites, which can be a problem when one wants to import text from
Wikipedia, use recent extensions, create a Wikipedia-related testwiki etc. The
trunk, on the other hand, is unreliable; the best solution is to use the exact
same revision which runs on the live sites, but that is somewhat inconvenient to
do manually. It would be nice to have a live branch or tag that contains the
same version that is used on Wikipedia.
(Or maybe it might be even better if the branch follows Wikipedia's version with
a few days delay - sometimes serious errors are found only when an update is
pushed to Wikipedia, but those are always fixed very quickly.)


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] More aggressive DEFAULTSORT

[Tisza Gergő]

Aryeh Gregor Simetrical+wikilist at gmail.com writes:

 On Thu, May 14, 2009 at 10:34 AM, Marcus Buck wiki at marcusbuck.org 
 wrote:
  Take the pagename and make it uppercase (could be lowercase too, but
  uppercase seems better as the first letter will show up in the
  category). str_replace Ä with A, Ö with O, Ü with U and ß
  with SS. Also str_replace other Latin characters with diacritics with
  their counterpart without diacritic. And that's our sortkey. This very
  simple procedure should reduce the number of necessary defaultsorts
  (except for articles about persons) by about 90% in the German wikipedia.
 
 This would absolutely be possible as a mostly works solution for
 category sorting.It would mostly just need to have the appropriate
 code written. 

Most of that can be done with one single language-independent algorithm. All the
collation rules I've seen until now fall into one of four categories:

1. you just need to transform to lowercase and discard diacritics (and space,
punctuation etc.). That is, you can do a Unicode decomposition and then throw
out everything from the combining ranges. I think there are very few languages
where that would be fully correct (for example it doesn't handle the German ß),
but it would make sorting a lot less wrong, at least for Latin scripts. (For
example, orr  őr  ott is incorrect in Hungarian as ő should be sorted after o,
but it is still a lot better than putting ő way down after z.) And it only has
to be written once.

2. you need a translation table with string replacement rules like ö = o, ő =
o~, ß = ss. Works for most languages with Latin letters and probably a lot of
others. Needs per-language rules, but it is much easier to ask language
communities to provide translation rules than to ask them to write sorting code
(and then review it). Most wikis probably already developed those rules and use
them with DEFULTSORT.

3. you need a multipass replacement with multiple translation tables (and you
concatenate the result using some sort of separator character). Theoretically
two passes should be done for a lot of languages (they define equivalence
classes for the accented characters in the first pass, then sort on the accents
in the second), but in practice you get the right result when you do one pass
and then sort on (sortkey, page_title) in the queries. Still, there are a few
languages where you need multiple passes (such as Thai, where you sort on
consonants first, and only after that on vowels).

4. in some languages such as Chinese it is impossible to sort correctly without
a dictionary.

Coding the first or second type of collation rule seems relatively simple, and
already a huge gain. (Also, RFC 3454 might be worth checking out as it has
language-independent rules for more than diacritics.)

 The only serious problem with it is that if the rules
 for automatic default sorting changed, a script of some sort would
 probably have to reparse all pages in some cases to figure out the
 original sort key provided, which would be kind of expensive.

You can have a separate raw_sortkey column if that's a large concern. Anyway,
this is the same for any solution that does not rely on MySQL collation: when
the rules change, you need to update the relevant column in the database.

What are the chances that we get decent MySQL collation in the close future
(say, next few years)? Bug 164 was opened 5 years ago, there is no point in
waiting another 5 years for database-level collations (and we do get them, the
system proposed in this thread can be removed without any complication). Waiting
forever will only result in people implementing the same solution with
DEFAULTSORT, either by hand (huge waste of resources) or with bots (even more
expensive than a built-in algorithm).


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [48735] trunk/phase3/includes/specials/SpecialRecentchanges.php

[Tisza Gergő]

 Revision: 48735

 Author:   midom

 Date:     2009-03-24 10:44:24 + (Tue, 24 Mar 2009)

 Log Message:

 ---

 change limit to reflect one in interface. :)

 Modified Paths:

 --

    trunk/phase3/includes/specials/SpecialRecentchanges.php

 Modified: trunk/phase3/includes/specials/SpecialRecentchanges.php

 ===

 --- trunk/phase3/includes/specials/SpecialRecentchanges.php 2009-03-24 
 09:59:13 UTC (rev 48734)

 +++ trunk/phase3/includes/specials/SpecialRecentchanges.php 2009-03-24 
 10:44:24 UTC (rev 48735)

 @@ -55,7 +55,7 @@

   $this-parseParameters( $parameters, $opts );

 }

 -   $opts-validateIntBounds( 'limit', 0, 5000 );

 +  $opts-validateIntBounds( 'limit', 0, 500 );

 return $opts;

   }

Was this necessary for performance reasons? A lot of people were using
500 recentchanges lists, some wikis even had them as options on the
RC interface (see
http://hu.wikipedia.org/wiki/MediaWiki:Recentchangestext for example).
If it was only changed for aesthetic purposes, please change it back,
or make it a site option.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l