Steve Bennett wrote:
> On 8/15/06, David Gerard <dgerard(a)gmail.com> wrote:
>
>> How is it in the Classic or Simple skin?
>>
>
> Is there a way where you can get the simple view, without having to go
> through preferences? It'd be great if we had something like
> en.wikipedia.org/wikisimple/Some_Page...
>
> Steve
> _______________________________________________
>
Just a thought: mobile phone and PDA users will generally be using
specialized browser software, doing so through HTML-to-WAP gateways, or
proxies that attempt to simplify pages for rendering on small screens.
If we could auto-detect these by User-Agent string, and use a custom
skin for these clients, we could greatly improve the experience for
small-screen users.
I've found lists of mobile client browser strings at
http://www.zytrax.com/tech/web/mobile_ids.html and
http://www.cantoni.org/2005/02/03/mobile-ua
Google's wireless proxy apparently reports itself as
"Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Google
Wireless Transcoder;)", according to
http://cleverhack.com/2006/08/06/google-wap-proxy-user-agent/
and some information on the i-mode user agent is provided here:
http://www.nttdocomo.co.jp/english/p_s/i/tag/s2.htmlhttp://www.nttdocomo.co.jp/english/p_s/i/spec/useragent.html
There is a sourceforge project that provides a LGPL'd Perl class for
mobile user agent sniffing which claims to work correctly for over 2000
different mobile devices:
http://sourceforge.net/projects/mobileuseragent/
-- Neil
I just made two different changes that didn't "stick".
One didn't show up on the page after I submitted, but when I went
to the edit page and resubmitted, I got an edit conflict, i.e. my
previous change showed via the action=edit, but not action=view.
Refreshing the edit page and making another, minor change made
the first change show up.
Then I made a change to a different page, and it did show up, but
disappeared (i.e. silently reverted) a few minutes later, not
even showing in history.
(If it matters, the two pages were
http://en.wiktionary.org/wiki/Wiktionary:Beer_parlour and
http://en.wiktionary.org/wiki/User:Scs.)
"Platonides" wrote:
> > Okay, so instead, and only slightly more expensive, go ahead
> > and hit the counter, but the counter does the randomization check - if
> > it's
> > the 1 in 1000, run the code that posts to the database.
> But then we fail in the original problem. A server with billions of
> conections... die.
>
Okay - honestly, I don't have experience with anything approaching that kind
of volume, so I can't speak intelligently about it.
I suppose it would be possible to, instead, only include the counter
javascript in the page (from the server serving the page) one time in 1000,
and use some kind of a shared key system to validate in the counter script.
But at that point, we're adding overhead to the mediawiki server, which is
exactly what we're trying to avoid.
I think it'd be better (and possible) to heuristically identify bad entries
getting posted by malicious users who hack the javascript (although the
shared key solution would be fun to design).
Just to enlighten me: would a gazillion GET requests take down a server
that quickly? I guess it takes a non-insignificant amount of processing
power just to handle the requests...
Aerik
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi there,
I've today developed an extension based on Special:Makesysop that may be a
solution to the problems (at least on en: ) with the process of gaining
adminship. Part of the problem with adminship is that it is somewhat
difficult to remove. This extension may change that. The extension, as
currently configured, allows local bureaucrats to desysop a user. I believe
that this is sensible. If we can trust bureaucrats to set the sysop bit, why
shouldn't we trust them to remove it? Additionally, desysopping is quite a
political issue, and generally requires the intervention of somebody
*familiar with the situation*, not an outsider who has simply been informed.
Therefore, I suggest that we use this extension to allow Bureaucrats to
desysop users in serious cases of abuse of powers. A different process for
desysopping may need to be developed to accompany this - and a policy on
when bureaucrats may use this ability.
Questions, comments and requests for demonstrations are more than welcome.
Andrew Garrett (Werdna)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (MingW32)
iD8DBQFE4aI7ehR2FitQhwARAmX5AKCtfLYt961WAwv0rikgfmbbqqP9SwCgo/0P
UHgmSXxVjXYcgxG5H+AS5qA=
=9mLX
-----END PGP SIGNATURE-----
A mediawiki question. At work, I have some text that looks something like:
*some text {{template}}
*some text
etc. I would like to make this entire block of text turn grey.
Ideally, I would do it like this:
{{grey|
*some text {{template}}
*some text
}}
But this doesn't work - the parser doesn't like it (afaik). With
various testing, I came up with a template like this:
{{grey(}}
*some text {{template}}
*some text
{{)}}
where {{grey(}} opens a table with certain character formatting,
creates a cell, and {{)}} closes the cell and table. Just applying the
style directly to the text didn't work. Even using divs and spans
didn't work.
Is there any remotely elegant way of doing all this?
Steve
>
>
>
> On Tue, Aug 15, 2006 at 03:50:25PM +0200, Jan Kulveit wrote:
> > On Tue, Aug 15, 2006 at 02:04:37PM +0200, Jens Frank wrote:
> >
> > Than, there must be some flaw in the implementation. Othervise the
> method
> > (running some client-side javascript contacting statistics server) is
> > industry standard (e.g. Google Analytics works this way).
> >
> > Moreover, it could be easily done with modest hardware and existing
> > statistics software. It's unnecessary to process the whole huge dataset
> -
> > it would be enough to process random selection. Which can be easily done
> > with JS ... the JS code would contact the statics server if some
> $random>0.999
> > for example.
>
> That's exactly how the JS for the German wiki works and that's also why
> it doesn't work. With only a few requests you can fake the statistics,
> since every hit on the statistics server counts as 1000 page views.
>
> Hmm... You'd have to purposefully hack the javascript, otherwise those
"few requests" would have a slim chance of being the 1 in a 1000 that gets
posted. So that must mean there is someone maliciously messing with the
statistics? Okay, so instead, and only slightly more expensive, go ahead
and hit the counter, but the counter does the randomization check - if it's
the 1 in 1000, run the code that posts to the database. You could even have
the counter script that gets run every time be very, very slim: just a
random number generator and an if statement, then do an include if the
condition is met (so you don't even load all the code into memory). You
could also opt to send back no response, and that saves some bandwidth too
(doesn't it?)... So you'd hit the server with a zillion GET requests, but
it wouldn't have to do much to deal with them.
Also... unless they're so determined that they're using a proxy to spoof the
statistics, you could look for an unusual number of hits from specific
IPs...
Aerik
Hi, I would like to transclude ((User:Kungfuadam/Status}} onto another Wiki.
I used the format {{:en:User:Kungfuadam/Status}}. Apparently the media wiki
software doesn't allow cross-project transclusions, but this would be a nice
feature.
--
Adam J. Lorenz
Charleston, SC
On 15/08/06, Ray Saintonge <saintonge(a)telus.net> wrote:
> Steve Bennett wrote:
> >There are various tools around that will automatically monitor the
> >pages of your choice on the web, wherever they are. I think there are
> >even tools that turn those changes into an RSS thread.
> >Actually, for that matter, I have a vague recollection MediaWiki can
> >generate an RSS feed from changes to pages, but I can't find any more
> >info on that atm.
> I suspect that this idea may be easier to implement once single sign-on
> is active. This should not prevent us from having separate talk pages
> on each project that interests us.
Mm. I tend to note on my talk pages elsewhere to leave me messages on
my en: talk page so I'll ever see them.
Wikia has almost-single-signon, I think - most of the Wikias share a
login database. Uncyclopedia is separate, I think Memory Alpha is
separate.
This is one for wikitech. Hey, is there any likelihood of RSS feeds or
email being switched on any time, just in case you feel like there
isn't enough smoke coming out of the servers?
- d.
Hi everyone,
There appear to be two separate discussions going on here... 1) whether
wikiwyg is good/bad and all the permutations thereof, and 2) what's up
with wikiwyg and SocialText/Wikia?
There are many pros and cons for #1 and it looks like this is a pretty
healthy debate to which I'm not qualified to add anything. However, I
can definitely shed some light on #2.
SocialText has developed a pretty nice wikiwyg interface for simple
editing that they wanted to donate to MediaWiki... the issue was that
they aren't currently using MediaWiki so they wanted some help in
bringing it over and they also wanted a demo to show at WikiMania to
demonstrate proof-of-concept. The idea was to get feedback on it at
WikiMania to determine if this would be something the community would be
interested in before trying to submit it to svn, etc. The good news is
that there was plenty of interest.
We (Jimmy/Wikia) offered to help and so Jason was helping to make their
code MediaWiki friendly and also put it into its own extension to make
working on it cleaner (not yet complete). The main participants in this
were Ingy and Gugod (SocialText), Travis (wikiHow), and Jason (Wikia).
In order to make a proof-of-concept demo practical, we reduced the scope
of what the wikiwyg editor would do so that we'd have something to show
by the time WikiMania rolled around. Currently, it does the following:
* Basic in-page rich text editing (bold, italics, bullets, links, etc)
which is saved as wikitext.
* Recognizes when there is wikitext on the page that it can't parse and
defaults to an in-page editor that just lets you edit the wikitext like
normal.
* Defaults to "disabled" on the page and you can enable it via
a left-nav bar option.
The plan was also to have a drop-down list of simple templates that
users could choose from and, as time permitted, start expanding that
list as the wikiwyg functionality was increased. Obviously, this sort of
thing will not spring out of Zeus' head full-grown, so this seemed like
a good compromise to start with. One thing I do want to clear up is that
we're not "being paid" to do this... we have *plenty* of other stuff on
our to-do lists. This is a really interesting project so we decided
to volunteer some time for it... same with SocialText and good for them
to throw in code they'd already written.
As for the current discussion about whether wikiwyg is good or not, I
can't contribute anything from the technical side but one thing to
consider is that when introduced to some sites, wiki page editing went
up 30% per month after introduction. So there are definite benefits to
having a simpler editing interface. My own personal opinion is that with
new tools come new ways of maintaining the quality of the content.
Making things more available does not have to correlate to lesser
quality. Actually, I believe the essence of the "lower barrier to entry
= lesser quality" argument was originally applied to the concept of
Wikipedia itself, wasn't it? (Not trying to be flippant... it just struck
a similar chord for me). That's not to say that the introduction of
wikiwyg won't pose new challenges, but I would argue that Wikipedia has
had greater challenges and managed to come out the better for them... I
wouldn't expect anything different here.
As for what's going on now with it .... we don't pretend to know the
best way to proceed with this... the next step of functionality isn't an
easy or straightforward problem. So I would sum it up this way...
proof-of-concept is done and the next phase is that we put this in the
right place in the repository so that any further development is done in
the right way by people who know MediaWiki best.
Can you please tell us what we should do next and who can help us to further
this effort and do the right thing here??
Thanks,
John Q.
p.s., to clear up something said earlier... Wikia is primarily GFDL although a few
wikis are Creative Commons because they started that way. Any code contributions
made would of course be GPL.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> -----Original Message-----
> From: wikitech-l-bounces(a)wikimedia.org [mailto:wikitech-l-
> bounces(a)wikimedia.org] On Behalf Of Rotem Liss
> Sent: Tuesday, August 15, 2006 10:27 PM
> To: Wikimedia developers
> Subject: [Wikitech-l] Proposal for an improved user rights page
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In the previous discussion (about Special:Desysop), it was proposed to
> merge the user rights pages (Special:Userrights, Special:Makesysop,
> Special:Makebot, Special:GiveRollback, and now also Special:Desysop)
> into the page Special:Userrights, using configuration settings. It seems
> to be a good time to propose it:
>
> I've merged these special pages to Special:Userrights using
> configuration settings in
> http://svn.wikimedia.org/viewvc/mediawiki/branches/rotem/userrights ,
> which is an improved user rights page.
>
> This proposed system adds the following features to Special:Userrights:
> * Flexible configuration settings for a limited interface - for example,
> you can allow bureaucrats to grant only these permissions and revoke
> only those permissions, and allow the stewards to do everything.
> * Checkboxes instead of lists, mainly because it's possible to disable
> them separately while it's not possible in lists.
> * Changing the permissions of remote users for stewards, controllable by
> a permission ("userrights_remote"), like in the stewards interface of
> Special:Makesysop.
> * Log comment, to explain the change, like in Makebot.
>
> You can either download and test it directly, or watch the following
> images:
>
> http://img150.imageshack.us/my.php?image=mediawikinewuserrightsbureaucrats
> lm9.png
> The limited interface for bureaucrats, like it can be set in Wikimedia
> sites.
>
> http://img84.imageshack.us/my.php?image=mediawikinewuserrightsstewardsgg7.
> png
> The full interface for stewards, like it can be set in Wikimedia sites,
> editing a remote user.
>
> This change should deprecate Makesysop, Makebot, GiveRollback and
> Desysop and make them implementable by using only configuration
> settings. However, these extensions may be kept for old versions, and
> for sites which were not updated. (There seems to be a compatibility
> issue with Special:Makesysop because one of its core functions
> (HTMLSelectGroups) was removed, but it can be defined in
> SpecialMakesysop.php or SpecialMakesysop_body.php as a class function.)
>
> Additional technical information may be found in
> http://www.mediawiki.org/wiki/User:Rotemliss/User_rights_suggestion#How_to
> _use_it
> . You can also read the other parts of the page, but it's a bit old and
> not updated in some parts. You can also ask here about anything unclear.
>
> What do you think about this implementation? Which changes should be
> done? Do you think some features should be added, or dropped?
>
> Thank you very much for the feedback.
>
> - --
> #define Name RotemLiss
> #define Mail mail-AT-rotemliss-DOT-com
> #define Site www.rotemliss.com
>
> #define KeyFingerPrint 4AFD 8579 A449 4267 BED9 38E5 6EF8 5B1F EBDE 7AC0
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFE4b2abvhbH+veesARApwWAKCq1TGg1zVjTIjwDiH3f7AVe0sbGQCfV7hJ
> NCU2Uwu1nrCv9ReNhVtaIxw=
> =CBQh
> -----END PGP SIGNATURE-----
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Ouch. My dreams of appearing on Special:Version are vanishing.
Seriously, though. Nice work.
Andrew Garrett (Werdna)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (MingW32)
iD8DBQFE4b45ehR2FitQhwARAqtGAKCNnP+9MF2NrRTlQCZR8yp3Yre5/wCfTmgK
Zl5MPZEJv3O+se+Ob86RB2A=
=bSB1
-----END PGP SIGNATURE-----