[Wikitech-l] LiquidThreads namespaces active on Wikimedia wikis but Lqt not active

[Siebrand Mazeland]

It looks like some change in the software for Wikimedia recently caused four 
namespaces for LiquidThreads to become active in many (all?) Wikimedia wikis, 
even if LiquidThreads is not reported as installed on Special:Version for the 
wiki.

An issue was created by MZMcBride noting a breaking API change because 
"LiquidThreads API namespaces don't include canonical key"[1].

Werdna commented on IRC, as also included in the issue report, this is some 
"hugely annoying" "feature of the localisation cache".

Siebrand

[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=24837


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

Re: [Wikitech-l] Storing data across requests

[Michael Dale]

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=markup&pathrev=53825
  
line 145 ( doSessionIdDownload )

--michael

___
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?

[David Gerard]

On 17 August 2010 21:39, Ryan Kaldari  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] Architectural revisions to improve category sorting

[Aryeh Gregor]

On Tue, Aug 17, 2010 at 4:45 PM, Nikola Smolenski  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] Storing data across requests

[Bryan Tong Minh]

On Sat, Jul 31, 2010 at 1:07 AM, Chad  wrote:
> On Fri, Jul 30, 2010 at 3:57 PM, Platonides  wrote:
>> Bryan Tong Minh wrote:
>>> Also, on places where no memcached or equivalent is available (i.e.
>>> CACHE_NONE), this will not work.
>>
>> Then you could be using the objectcache table in the database.
>>
>>
>
> No, that's CACHE_DB. CACHE_NONE really means what it
> says.
>
I could force the usage of the objectcache table even for CACHE_NONE
by creating my own cache object with wfGetCache( CACHE_DB ); Are there
any objections for (ab)using the objectcache table for this purpose?


Bryan

___
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

[Nikola Smolenski]

Дана Tuesday 17 August 2010 22:11:32 Aryeh Gregor написа:
> On Tue, Aug 17, 2010 at 4:06 PM, Nikola Smolenski  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] Vector skin failures on mobile phones - any timeframe for a fix?

[Ryan Kaldari]

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 Gerard  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] Vector skin failures on mobile phones - any timeframe for a fix?

[Magnus Manske]

On Tue, Aug 17, 2010 at 7:17 PM, David Gerard  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

Re: [Wikitech-l] Architectural revisions to improve category sorting

[Conrad Irwin]

On 17 August 2010 13:06, Nikola Smolenski  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] Architectural revisions to improve category sorting

[Aryeh Gregor]

On Tue, Aug 17, 2010 at 4:06 PM, Nikola Smolenski  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

[Nikola Smolenski]

Дана 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

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

[Wikitech-l] Vector skin failures on mobile phones - any timeframe for a fix?

[David Gerard]

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

[Wikitech-l] Demo for XMPP-Based RC-Notifications

[Daniel Kinzler]

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,
 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  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