[Wikitech-l] Demo for XMPP-Based RC-Notifications
Hi all. I have wanted to push RC-messages via XMPP for a long time. I have now a working demo on the toolserver: join enw...@conference.jabber.toolserver.org with any jabber client to see the human readable part. The demo works by polling the API, for production use, http://www.mediawiki.org/wiki/Extension:XMLRC should be enabled on the live sites. The architecture is similar to the one used for the IRC channels: MediaWiki emits UDP packets (in the case of XMLRC, containing XML - the same rc tags you would get from the API). The packets are received by a standalong bridge process (written in python) that multiplexes the messages into the appropriat channels (XMPP MUC rooms, in my case). Details can be found on the extension page. I have also written a small client lib that provides convenient access to the RC properties that are enclosed in the XMPP message. See the extension page for links. So, what do you think, what would it take to get this live? -- daniel PS: relevant tracking bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=17450 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Vector skin failures on mobile phones - any timeframe for a fix?
Vector is still a miserable failure for mobile phone users. Is there any timescale for this being fixed? At the very least, graceful degradation put into place? Latest bug report (from a friend in a Facebook conversation): mazing. conservapedia still works on my mobile, wikipedia doesn't. htc touch pro 2, windows mobile 6.1 pro, using internet explorer (because opera is a steaming pile of shit). not sure what version of IE... yeah, wikipedia used to work marvelously, i've completely stopped using it since the update - i only... ever used it to look things up in the pub anyways, anywhere else i'd need better cites :P Please. Save our readers from having to use Conservapedia instead, just because Monobook works and Vector doesn't! - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Architectural revisions to improve category sorting
The code is currently enabled in trunk and is still awaiting review. It's basically complete, but there are some issues left: * What sortkey algorithm to use? Currently it just ASCII uppercases the words, which is okay for a proof-of-concept but doesn't actually solve bug 164. * What should be done about compatibility, particularly given the schema change? Should I try to convert all the extensions I've broken? Should we keep the old cl_sortkey index so that out-of-tree uses don't suddenly become extremely inefficient (but then we have to maintain an extra largely pointless index)? * On a much more minor note, cl_sortkey should probably be redefined to varbinary(255), instead of varchar(70). I'd do this, but I'm not totally sure about it, so I'm awaiting feedback from Tim, since it would be annoying to convert it and then convert it back. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Architectural revisions to improve category sorting
Дана Tuesday 17 August 2010 20:37:44 Aryeh Gregor написа:
The code is currently enabled in trunk and is still awaiting review.
It's basically complete, but there are some issues left:
* What sortkey algorithm to use? Currently it just ASCII uppercases
the words, which is okay for a proof-of-concept but doesn't actually
solve bug 164.
For some time now, I am thinking about a stupidly simple solution:
php -r 'for($i = 0; $i 65536; $i++) { echo pack(nx, $i); echo \n; }'|
iconv -f ucs-2be -t utf8 | sort | php -r 'foreach(file(php://stdin) as $v)
{ echo var_export(substr($v, 0, -1)) . = \ . str_pad(base_convert($i,
10, 36), 4, 0, STR_PAD_LEFT) . \,\n; $i++; }'
This, more or less, should:
- Print every Unicode (UCS-2 only) character on its own line
- Sort that according to the current locale
- Print a PHP array to replace each Unicode character (UTF-8 encoded) with
appropriate base36 number
If an UTF-8 string is encoded with this array, the resulting strings should be
sorted exactly the same as in the locale through mere ASCII sorting. Or am I
missing something big? (Except contextual sensitivity, but it occurs
relatively rarely and this should still be better than what we have now.)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Architectural revisions to improve category sorting
On Tue, Aug 17, 2010 at 4:06 PM, Nikola Smolenski smole...@eunet.rs wrote:
For some time now, I am thinking about a stupidly simple solution:
php -r 'for($i = 0; $i 65536; $i++) { echo pack(nx, $i); echo \n; }'|
iconv -f ucs-2be -t utf8 | sort | php -r 'foreach(file(php://stdin) as $v)
{ echo var_export(substr($v, 0, -1)) . = \ . str_pad(base_convert($i,
10, 36), 4, 0, STR_PAD_LEFT) . \,\n; $i++; }'
This doesn't account for how complicated proper locale-specific
sorting is. Multi-character strings do not sort just based on
splitting them into characters and sorting those. You can have the
same character sorting differently in different contexts. There are
well-established libraries for Unicode sorting, and we certainly
should not try to reinvent the wheel here.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Architectural revisions to improve category sorting
On 17 August 2010 13:06, Nikola Smolenski smole...@eunet.rs wrote:
Дана Tuesday 17 August 2010 20:37:44 Aryeh Gregor написа:
The code is currently enabled in trunk and is still awaiting review.
It's basically complete, but there are some issues left:
* What sortkey algorithm to use? Currently it just ASCII uppercases
the words, which is okay for a proof-of-concept but doesn't actually
solve bug 164.
For some time now, I am thinking about a stupidly simple solution:
php -r 'for($i = 0; $i 65536; $i++) { echo pack(nx, $i); echo \n; }'|
iconv -f ucs-2be -t utf8 | sort | php -r 'foreach(file(php://stdin) as $v)
{ echo var_export(substr($v, 0, -1)) . = \ . str_pad(base_convert($i,
10, 36), 4, 0, STR_PAD_LEFT) . \,\n; $i++; }'
This, more or less, should:
- Print every Unicode (UCS-2 only) character on its own line
- Sort that according to the current locale
- Print a PHP array to replace each Unicode character (UTF-8 encoded) with
appropriate base36 number
If an UTF-8 string is encoded with this array, the resulting strings should be
sorted exactly the same as in the locale through mere ASCII sorting. Or am I
missing something big? (Except contextual sensitivity, but it occurs
relatively rarely and this should still be better than what we have now.)
You are missing most of it :). In many cases a single letter is made
up of multiple code-points (of which there are considerably more than
65536 by the way) - think of Hungarian gy, then there are all kinds of
conventions for sorting accents - in French you sort á after a but
only if the rest of the word is spelt the same (i.e ab - áb - ac).
There is the ICU, and it is available to PHP (in some versions)
http://docs.php.net/manual/en/class.collator.php, using those sort
keys should be good enough for now I imagine. There are languages on
Wiktionary that won't be in the ICU yet (just because they are
ludicrously obscure) but it's probably best to start with something
manageable.
Conrad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Vector skin failures on mobile phones - any timeframe for a fix?
Aren't most mobile browsers supposed to be redirected to mobile.wikipedia.org anyway? BTW, we are slowly fixing Vector issues for obscure browsers. For example, I just recently fixed Vector for the PS3's browser. To fix these issues we need 2 things: A complete description of the environment and display behavior (preferably with a screenshot or even a photo of your cell phone screen), and a way to test it. For some mobile phones we can use emulators, but for others we have no easy way to test Vector on them. Ryan Kaldari On 8/17/10 1:20 PM, Magnus Manske wrote: On Tue, Aug 17, 2010 at 7:17 PM, David Gerarddger...@gmail.com wrote: Vector is still a miserable failure for mobile phone users. Is there any timescale for this being fixed? At the very least, graceful degradation put into place? Latest bug report (from a friend in a Facebook conversation): mazing. conservapedia still works on my mobile, wikipedia doesn't. htc touch pro 2, windows mobile 6.1 pro, using internet explorer (because opera is a steaming pile of shit). not sure what version of IE... yeah, wikipedia used to work marvelously, i've completely stopped using it since the update - i only... ever used it to look things up in the pub anyways, anywhere else i'd need better cites :P Please. Save our readers from having to use Conservapedia instead, just because Monobook works and Vector doesn't! Just switch to Discover :-) http://thenextweb.com/apps/2010/08/17/discover-by-cooliris-is-the-slickest-wikipedia-skin-for-ipad/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Architectural revisions to improve category sorting
Дана Tuesday 17 August 2010 22:11:32 Aryeh Gregor написа:
On Tue, Aug 17, 2010 at 4:06 PM, Nikola Smolenski smole...@eunet.rs wrote:
For some time now, I am thinking about a stupidly simple solution:
php -r 'for($i = 0; $i 65536; $i++) { echo pack(nx, $i); echo \n;
}'| iconv -f ucs-2be -t utf8 | sort | php -r 'foreach(file(php://stdin)
as $v) { echo var_export(substr($v, 0, -1)) . = \ .
str_pad(base_convert($i, 10, 36), 4, 0, STR_PAD_LEFT) . \,\n; $i++; }'
This doesn't account for how complicated proper locale-specific
sorting is. Multi-character strings do not sort just based on
splitting them into characters and sorting those. You can have the
same character sorting differently in different contexts. There are
well-established libraries for Unicode sorting, and we certainly
should not try to reinvent the wheel here.
All right; but right now we are not paying attention to character context too,
and not properly sorting even single characters. I mean, we are sorting Ђ
before А! Surely this would be an improvement?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Architectural revisions to improve category sorting
On Tue, Aug 17, 2010 at 4:45 PM, Nikola Smolenski smole...@eunet.rs wrote: All right; but right now we are not paying attention to character context too, and not properly sorting even single characters. I mean, we are sorting Ђ before А! Surely this would be an improvement? Yes, but it would probably be easier to just use CLDR or ICU to begin with, rather than trying to write and debug our own sort function. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Vector skin failures on mobile phones - any timeframe for a fix?
On 17 August 2010 21:39, Ryan Kaldari rkald...@wikimedia.org wrote: BTW, we are slowly fixing Vector issues for obscure browsers. For example, I just recently fixed Vector for the PS3's browser. To fix these issues we need 2 things: A complete description of the environment and display behavior (preferably with a screenshot or even a photo of your cell phone screen), and a way to test it. For some mobile phones we can use emulators, but for others we have no easy way to test Vector on them. Doubt I can draft this user into such testing - as far as they're concerned, Wikipedia deliberately broke itself so therefore it's Wikipedia's stupidity. (And this is not an unreasonable description of how it happened.) A suggestion: post to the techblog with precisely what you need from what classes of users. This can then be spread around the bogosphere and recruit all the help with browser issues you could want. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Storing data across requests
On 07/29/2010 10:15 AM, Bryan Tong Minh wrote: Hi, I have been working on getting asynchronous upload from url to work properly[1]. A problem that I encountered was that I need to store data across requests. Normally I would use $_SESSION, but this data should also be available to job runners, and $_SESSION isn't. Could the job not include the session_id and upload_session_key .. then in your job handling code you just connect into that session via session_id( $session_id ); session_start(); to update the values ? . That seems like it would be more lightweight than DB status updates. .. I see Platonides suggested this as well.. ( that is how it was done originally done but with a background php process rather than jobs table ) see http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/HttpFunctions.php?view=markuppathrev=53825 line 145 ( doSessionIdDownload ) --michael ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
