Re: [Wikitech-l] js2 extensions / Update ( add-media-wizard, uploadWizard, timed media player )

[Maciej Jaros]

On 2010-05-14 05:44, Michael Dale wrote:
> If you have been following the svn commits you may have noticed a bit of
> activity on the js2 front.
>
> I wanted to send a quick heads up that describes what is going on and
> invite people to try things out, and give feedback.
>
> == Demos ==
>
> The js2 extension and associated extension are ruining on sandbox-9. If
> you view the source of a main page you can see all the scripts and css
> and grouped into associated buckets:
> [...]
>

So does this extensions encrypt JS files into being non-debugable? I 
could understand that on sites like Facebook but on an open or even Open 
site like Wikipedia/Mediawiki? This just seems to be wrong. Simple 
concatenation of files would serve the same purpose in terms of requests 
to the server.

Regards,
Nux.

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

Re: [Wikitech-l] Anyone with CSS fu that can help out on Flagged Revs?

[Maciej Jaros]

At 2010-05-30 17:45, Aryeh Gregor wrote:
> On Fri, May 28, 2010 at 12:43 AM, Rob Lanphier  wrote:
>
>> What we're struggling with is that the "[review pending revisions]" with the
>> little lock icon beside it to look right in a cross-browser and cross-skin
>> fashion.  A couple of the problems we're seeing:
>> 1.  In Vector, the placement of the text can be too high or too low,
>> depending on the browser in use
>> 2.  In Monobook, the problem is even worse.  For example, in Chrome on
>> Linux, the text hovers way up above article, covering up the "My
>> contributions" link, for example
>>  
> Try just putting your div right before the  or
> equivalent, and float: right it.  You can put some margins or padding
> on the top and/or right to adjust it a bit if you like.  Something
> like that should work.  This will be much more reliable than trying to
> absolutely position it, because different skins will use different
> heights, and the heights won't be consistent at all in the face of
> things like site notices.
>

I agree. Don't use CSS for positioning if you can do it better. Except 
for the problems mentioned by others there is a box model problem:
http://en.wikipedia.org/wiki/Internet_Explorer_box_model_bug
Which might be a problem as #content has padding.

Regards,
Nux.

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

Re: [Wikitech-l] Anyone with CSS fu that can help out on Flagged Revs?

[Maciej Jaros]

At 2010-05-30 18:55, Aryeh Gregor wrote:
> On Sun, May 30, 2010 at 12:20 PM, Maciej Jaros  wrote:
>
>> I agree. Don't use CSS for positioning if you can do it better. Except
>> for the problems mentioned by others there is a box model problem:
>> http://en.wikipedia.org/wiki/Internet_Explorer_box_model_bug
>> Which might be a problem as #content has padding.
>>  
> We don't render in quirks mode and don't really care about anything
> before IE6, so thankfully, we don't have to worry about that.
>

Hm... Indeed... Weird. I haven't noticed that Wiki is shown in 
compatibility view just because of the by domain settings... That alone 
at least doesn't change much in horizontal positions of elements (only 
the search bar seems to be affected).

Still, using CSS for positioning is always risky unless an element to be 
positioned is anchored inside an element over which you want to position it.

Regards,
Nux

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

Re: [Wikitech-l] I need an extra tab.

[Maciej Jaros]

  At 2010-08-09 04:39, Mike.lifeguard wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Is there any documentation for this kind of client-side hacking? I
> suppose there are comments in wikibits.js... :)

AFAIK there are various Wikipedia pages in various languages that 
describe some tricks:
pl: 
http://pl.wikipedia.org/wiki/Pomoc:Personalizacja_-_porady_dla_zaawansowanych
en: http://en.wikipedia.org/wiki/Wikipedia:WikiProject_User_scripts/Guide
On meta I've only found some mostly outdated stuff here:
http://meta.wikimedia.org/wiki/Help:User_style

Regards,
Nux.

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

[Maciej Jaros]

  At 2010-08-18 21:50, Ryan Kaldari wrote:
> I just looked and I could only find 2 bugs filed about Vector not
> working on mobile devices. The first was for it being broken in NetFront
> browsers. This was fixed less than a month after being reported (and
> within a week of Wikimedia getting a device to test on). The second was
> for Vector crashing some blackberry phones. This was traced to a bug on
> Blackberry's side (the same day the bug was reported). A work-around was
> implemented a week later. Further testing was done on eight different
> models of blackberries and across 3 different Firmware versions. It was
> determined that phones upgraded to the v5 Firmware no longer crashed.
> That doesn't sound like Wikimedia being "slow to act".
>
> And for what it's worth, Vector was apparently tested on IEMobile. It
> worked in the tests, but of course it's impossible to test every version
> of every browser on every phone OS.
>
> Thanks for sending the user agent string, that will be useful for filing
> a bug in Bugzilla.

BTW. PPK made some tests for mobile phones and their browsers:
http://www.quirksmode.org/mobile/

He might shout a lot on devs ;-), but I think that the Foundation might 
convince him to make some tests in various phones (he has quite a lot of 
them). You would at least know for sure which must be switch to mobile 
version at all times and which should (might display some preference 
dialogue). Also dynamic switch to monobook for some phones might be nice.

Just some thoughts.

Regards,
Nux.

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

Re: [Wikitech-l] Developing true WISIWYG editor for media wiki

[Maciej Jaros]

  Hi.

Does anybody know which extension Wikia uses currently? On Wikia's SVN 
I've found the RTE extension[1], but I think they at least something 
extra for adding categories...

BTW. I think that usability might consider working from their version 
rather then developing everything from scratch. Wikia's editor seems to 
work quite well for most basic pages and doesn't seem to clutter code 
with unwanted tags. After some tests I can certainly say it's much 
better then the official version of FCKeditor extension [2].

[1] https://svn.wikia-code.com/wikia/trunk/extensions/wikia/RTE/
[2] http://www.mediawiki.org/wiki/Extension:FCKeditor_(Official)

Regards,
Nux.

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

Re: [Wikitech-l] Increasing default cookie expiry time

[Maciej Jaros]

  At 2010-08-24 14:51, Helder Geovane wrote:
> Would it be possible for a user to create a small javascript to replace the
> default cookie by another one which doesn't expires?
Probably not unless some browser don't respect HttpOnly flag of cookies.

But you could make an extension for a browser like Firefox and probably 
even GreaseMonkey script to do that.

Also some browsers (e.g. Opera) allow you to change cookie settings with 
their built in cookie managers. So you might set up cookie expiry for 
say... 2100-01-01 or something like that.

Regards,
Nux.

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

Re: [Wikitech-l] How to generate link to section in JavaScript?

[Maciej Jaros]

  At 2010-08-24 15:44, lampak wrote:
> On 24/08/10 15:25, Tgr wrote:
>> lampak   gmail.com>   writes:
>>
>>> Hi. I'm working on a script which edits a page, adds a section to it and
>>> then redirects to this page.
>>>
>>> It would be nice if it went straight to the newly-created section. So I
>>> need to create a link with # in it.
>>>
>>> The problem appears when the title of the section contains some
>>> diacritics. For example, link to "bażant królewski" looks like
>>> "Ba.C5.BCant_kr.C3.B3lewski".
>>>
>>> How can I generate in JavaScript such a link which would be identical to
>>> the one generated by MediaWiki? Has somebody written such a function? Or
>>> at least, do you know where it is done in MediaWiki php code?
>> It is pretty simple as long as there is no wikitext or html in the title:
>> convert it to urlencoded UTF-8 (encodeURIComponent does that), replace 
>> percent
>> signs with dots, replace spaces with underscores.
> I have tried encodeURIComponent before. Bażant królewski becomes
> Bażant_królewski. Diacritics are not converted. At least not under Firefox.
For basic examples you could use this:
var txt = 'Zażółć';
txt = encodeURIComponent(encodeURI(txt).replace(/%/g, 
'.')).replace(/%/g, '.');

Not sure if encodeURI was in old IE (if you care ;-)), but it works with 
new browsers.

Note that this will not work if the section contains mark up code. But 
as I understood you are not looking for something bulletproof.

Regards,
Nux.


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

Re: [Wikitech-l] Transaction nesting and savepoints

[Maciej Jaros]

  At 2010-08-31 19:09, Aryeh Gregor wrote:
> On Tue, Aug 31, 2010 at 11:08 AM, Platonides  wrote:
>> I propose changing Database::begin() / commit() / rollback() to keep the
>> count in mTrxLevel and perform a savepoint instead of a BEGIN should it
>> be called inside another one.
>>
>> Savepoints are a way to perform partial rollbacks inside a bigger
>> transaction. They are supported by all our databases [5] [6] [7] [8] [9]
>> [10]. We shouldn't even have problems with our 4.0.30
>> servers, since its support was added in mysql 4.0.14 [11].
> I think there would be performance issues with this.  Specifically,
> there are a number of places where we do a commit because we need to
> release locks immediately to avoid contention.  It looks like the
> locks are held until the transaction commit when savepoints are used,
> so this might make us hold a lot of locks for much too long.
> DatabaseBase should definitely be DBMS-neutral here, though, and
> should not depend on MySQL's behavior.  I suggest that begin() check
> the transaction level, and if there's an open transaction, it should
> do an explicit commit() first and wfWarn().  This kind of thing is a
> bug -- it will lead to less atomicity than it looks like we have from
> casual code inspection, and these cases should be looked at and fixed
> if possible.

I think it still should be conscious decision and so those functions 
could use their first... hm... second parameter as the transaction name. 
For MS SQL you can simply use BEGIN TRANSACTION [name] (I think it would 
be more natural), for MySQL I guess savepoints should be used.

Regards,
Nux.

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

Re: [Wikitech-l] Transaction nesting and savepoints

[Maciej Jaros]

  At 2010-09-01 17:03, Aryeh Gregor wrote:
> On Wed, Sep 1, 2010 at 2:42 AM, Maciej Jaros  wrote:
>> I think it still should be conscious decision and so those functions
>> could use their first... hm... second parameter as the transaction name.
>> For MS SQL you can simply use BEGIN TRANSACTION [name] (I think it would
>> be more natural), for MySQL I guess savepoints should be used.
> I'm not sure what you're saying here.  Are you suggesting some
> solution where commit() does not actually always commit the current
> transaction?  If so, as I said, this is a problem because it will
> cause locks to be held for much too long in some cases.
Not exactly. If you know you can and should commit transaction called 
for example "article_update" then it's OK. If you want to commit 
"image_insert_and_update" then it's OK too. If you are making a commit 
for everything that is started then it doesn't seem OK as pointed out by 
Platonides in his example.


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

Re: [Wikitech-l] Transaction nesting and savepoints

[Maciej Jaros]

  At 2010-09-02 01:04, Aryeh Gregor wrote:
> On Wed, Sep 1, 2010 at 6:47 PM, Platonides  wrote:
>> Is there some way to find out those points were the commit needs to be
>> there for lock freeing and not just for normal transaction finish ?
> Look at every single commit() and guess?  Alternatively, we could just
> assume none of them are for releasing locks, skip them and see what
> Domas comments out to fix the site when it breaks.  ;)

Maybe this could be done step by step by adding named transactions and 
some other other method/parameter like commitToUnlockTables so the 
developers using it would know what it is used for ;-). Commit (in 
general) is obviously not always done to simply unlock tables. Some 
might not expect changes be committed already and might want to rollback 
but they would be unable to.

So until proper handling of transactions would be implemented warnings 
might be thrown if begin/commit would not be called without proper 
attributes. An additional warning might be thrown if more then say... 3 
nested transactions would be started as it would probably mean locking 
too many tables.

This approach would catch this:
begin transaction outer_tran
update tbl1 set name='1234' --locks tbl1
begin transaction inner_tran
   update tbl2 set name='1234' -- locks tbl2
   begin transaction inner_inner_tran -- -> throw warning: too many 
open tran
  update tbl3 set name='1234' -- locks tbl3
   commit transaction inner_inner_tran
commit transaction inner_tran
commit transaction outer_tran

But then again it wouldn't catch this:
begin transaction outer_tran
update tbl1 set name='1234' --locks tbl1
begin transaction inner_tran
   update tbl2 set name='1234' -- locks tbl2
commit transaction inner_tran
begin transaction other_inner_tran
   update tbl3 set name='1234' -- locks tbl3, but no warning is 
thrown (and yes, MSSQL keeps tbl2 locked too)
commit transaction other_inner_tran
commit transaction outer_tran

And so (with the exception of installation and upgrade process) warnings 
might be thrown when you actually run to many inserts/updates after most 
outer transaction was started. Something like this would work I think:
if ($this->trxLevel()>0 &&  $this->isWriteQuery( $sql ))
{
$this->mNumWritesSinceTran++;// set to 0 on tran end
if ($this->mNumWritesSinceTran>TOO_MANY_WRITES_SINCE_TRAN)
{
   wfWarn( "Too many writes since most outer transaction started 
({$this->mNumWritesSinceTran}). Avoid locking tables when possible." );
}
}

Regards,
Nux.

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

Re: [Wikitech-l] ResourceLoader, now in trunk!

[Maciej Jaros]

  At 2010-09-04 05:59, Trevor Parscal wrote:
> * Allows minification of JavaScript and CSS.

Will JS/CSS developers/testers be able to disable this in preferences?

> * Allows deployment changes to all pages for all users within minutes,
> without purging any HTML. ResourceLoader provides a short-expiry
> start-up script which then decides to continue loading more JavaScript
> or not, and if so has a complete manifest of all scripts and styles on
> the server and their most recent versions,  Also, this startup script
> will be able to be inlined using ESI (see
> http://en.wikipedia.org/wiki/Edge_Side_Includes ) when using Squid or
> Varnish, reducing requests and improving performance even further.

So any change to MediaWiki:Common.js will refresh all script that are 
minified?

> * Help writing new code! While wikibits.js is now also known as the
> "mediawiki.legacy.wikibits" module, the functionality that it and
> basically all other existing MediaWiki JavaScript code provide is being
> deprecated, in favor of new modules which take  advantage of jQuery and
> can be written using a lot less code while eliminating the current
> dependence on a large number of globally accessible variables and
> functions (see
> http://www.mediawiki.org/wiki/ResourceLoader/JavaScript_Deprecations )

Will jQuery be available for older skins too? If so won't it cause 
problems for mobile browsers? AFAIK mobile jQuery will not be ready for 
at least next few years.

I'm asking here because those that make gadgets (well me at least ;-)) 
still try to make them work on Vector and Monobook.

> * Some patience and understanding... Please... While we are integrating
> into trunk, things might break unexpectedly. We're diligently tracking
> down issues and resolving them as fast as we can, but help in this
> regard is much needed and really appreciated. But most of all, we're
> sorry if something gets screwed up, and we're trying our best to make
> this integration smooth.
> * Enthusiasm!

Sorry for not being very enthusiastic ;-). I see this as solving some 
problems but creating new ones too. Not really complaining here, I think 
minification is really needed now to get Wikimedia sites loading faster.

Regards,
Nux.

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

Re: [Wikitech-l] ResourceLoader, now in trunk!

[Maciej Jaros]

  AT 2010-09-06 18:26, Roan Kattouw wrote:
> 2010/9/6 Maciej Jaros:
>>   At 2010-09-04 05:59, Trevor Parscal wrote:
>>> * Allows minification of JavaScript and CSS.
>> Will JS/CSS developers/testers be able to disable this in preferences?
>>
> Like I said in my previous reply to Aryeh, you can use debug mode.
> This is a feature we probably should've mentioned in the OP.

This is good, but an option set in preferences would be more efficient 
when debugging more then one page. But if it would read _GET or _COOKIE 
then it would be fine for me, too.

>>> * Help writing new code! While wikibits.js is now also known as the
>>> "mediawiki.legacy.wikibits" module, the functionality that it and
>>> basically all other existing MediaWiki JavaScript code provide is being
>>> deprecated, in favor of new modules which take  advantage of jQuery and
>>> can be written using a lot less code while eliminating the current
>>> dependence on a large number of globally accessible variables and
>>> functions (see
>>> http://www.mediawiki.org/wiki/ResourceLoader/JavaScript_Deprecations )
>> Will jQuery be available for older skins too? If so won't it cause
>> problems for mobile browsers? AFAIK mobile jQuery will not be ready for
>> at least next few years.
>>
> Yes, jQuery will be served on every page load. However, the (short)
> startup script that contains the module registration information and
> loads the jquery and mediawiki modules checks the browser version for
> compatibility before doing the latter. Currently the only browser it
> considers incompatible is IE<6, but this list should probably be
> extended to include other stone age browsers and mobile browsers. For
> the latter, we can even do the redirect to the mobile site in that
> place so we don't load a ton of JS before deciding to redirect people.
> OTOH, it might be nice to put a mobile redirect script in the
> so the browser doesn't have to render the entire page before it hits
> the redirect script.

That seems like a good idea. I've just found some data about jQuery tests:
http://jquerymobile.com/gbs/
As seems I was a little over pessimistic about jQuery for mobile 
devices. None the less you can use the table on the page for 
redirections. I think everything below B should be redirected to mobile 
version. B might be left on monobook and A should work fine with any 
skin (or least surrvive).

>> I'm asking here because those that make gadgets (well me at least ;-))
>> still try to make them work on Vector and Monobook.
>>
> That's one of the objectives here: to provide a common base library
> that everything in MW can build on, regardless of skin or whatever. To
> that end, we started serving jQuery on every page on Wikimedia wikis
> last week, and we already did so in trunk ($wgJQueryOnEveryPage) for a
> few months IIRC.

Cool. Just announced it on pl.wiki news page.

>> Sorry for not being very enthusiastic ;-). I see this as solving some
>> problems but creating new ones too. Not really complaining here, I think
>> minification is really needed now to get Wikimedia sites loading faster.
> Which problems would this introduce? The ones you mentioned in this
> post have either already been solved or are trivially solvable.

I fear mainly that there will be reproduction issues and I'm probably 
just a bit superstitious ;-). I'm also a bit worried how current various 
loading mechanism will accompany new ones.

Regards,
Nux.

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

Re: [Wikitech-l] Page display slowness

[Maciej Jaros]

  At 2010-09-09 01:20, Lars Aronsson wrote:
> For various reasons, I'm now using the Opera 10.10 browser on Linux.
> With the new vector skin, trying to open an edit form takes 4 or 5
> seconds. This is not because the servers are slow, the whole is quite
> fast in Firefox, but in Opera time elapses while executing the
> JavaScript that adds the toolbar above the main textarea and
> rearranges the left menu. During this time, I can sometimes set
> the cursor in the textarea, but two seconds later focus is gone,
> and I have to set the cursor again before I can start to edit.
>
> It was not this slow under the old monobook skin.
>
> I know I can go back to monobook, so don't tell me. I just wanted
> to report this. Perhaps there's some part of vector that can be
> improved.
First of all try 10.60 (or 10.61 to be more exact). Secondly there will 
be some improvements with load times when the ResourceLoader will be 
used. See:
http://www.mediawiki.org/wiki/ResourceLoader

Not sure if this would work for you thou as page rendering time might be 
actual stopper in your case. But new version of Opera is faster at that.

Regards,
Nux.

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

Re: [Wikitech-l] ResourceLoader, now in trunk!

[Maciej Jaros]

  At 2010-09-09 10:15, Trevor Parscal wrote:
>On 9/9/10 12:42 AM, Jean-Marc van Leerdam wrote:
>> Hi,
>>
>> On 9 September 2010 09:36, Tgr   wrote:
>>> Roan Kattouw   gmail.com>   writes:
>>>
 Actually, the line number would not mean a great deal because the
 scripts would still be combined, comments frequently take up entire
 lines and the deminifier cannot account for blank lines, statements
 broken over multiple lines, or multiple statements on one line. All
 this means it's impossible to map the line number to a source line and
 file, although I agree it does map it to a statement: someone else can
 add a breakpoint at the same line of the same combined+minified output
 (provided they're also hitting the same load.php URL) and have that
 break at the exact statement the reporter got their error on.
>>> It shouldn't be too hard to have the minification script create a line 
>>> number
>>> translation table; just delay stripping newlines until the end, and create 
>>> an
>>> index of newline positions in the original and minified versions of the 
>>> code.
>>> (You would need error offsets for that to be useful, though; I don't know 
>>> which
>>> browsers provide that.)
>>>
>> Why not leave line endings in place (with multiple line endings
>> trimmed to one)? Or are the line endings a significant part of the
>> minification gain?
>>
>>
> Or just use debug mode...
>
> The purpose of using the debug mode (a feature of ResourceLoader) is not
> only to not minify the code, but also to not concatenate. The difference
> in performance between debug-mode and normal mode is enormous, and
> trying to find middle ground is unlikely to be fruitful.
>
> Debug mode is useful, we should be embracing the concept and improving
> on it, rather than sacrificing the speed of the web-site as hundreds of
> millions of people experience it, just to appease lazy developers who
> don't want to type debug=true at the end of a URL.
>
> - Trevor

Why not making this set-able through cookies?
below:
 $this->debug = $request->getVal( 'debug' ) === 'true' || 
$request->getBool( 'debug' );
add something like:
if (!$this->debug)
{
 $cookieval = $request-> getCookie( 'debug', 'resource_loader_', 
false);
 $this->debug = (!empty($cookieval));
}

This would allow developers add debugging bookmark like this:
javascript:alert(document.cookie="resource_loader_debug=1;%20path=/")

Regards,
Nux.

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

Re: [Wikitech-l] ResourceLoader, now in trunk!

[Maciej Jaros]

  At 2010-09-09 21:18, Neil Kandalgaonkar wrote:
> I don't know about the rest of you, but I am the kind of person who
> would forget that they were in debug mode, or would leave it "on" all
> the time anyway.
>
> Just a suggestion, but if there's a cookie or pref I feel it should add
> something visible to the page, to let you know you are in debug mode.
> Maybe an extra CSS rule that changes the logo or something.
>
> Otherwise, I'm not looking forward to even more complaints about why the
> site is slow. ;)

I doubt developers will complain about that, but in any case the cookie 
will expire at the end of session (thought I know people that close 
their browser about once in a month or so ;-)). And besides as 
developers are developers they can add something to the page themselves. 
Personally I prefer to have a skin chooser on top of the page in my test 
mode.

Regards,
Nux.

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

Re: [Wikitech-l] Proposal: reversion collapsing in edit history

[Maciej Jaros]

  At 2010-09-12 22:09, Rob Lanphier wrote:
> [...]
>
> The text "4 revisions not shown" would be a hyperlink that would
> expose the collapsed revisions.  The revisions would still be
> available for everyone to view; they just wouldn't be given the same
> level of visibility as revisions that had a more lasting effect on the
> current article.
>
> I've drafted this up here:
> http://www.mediawiki.org/wiki/Pending_Changes_enwiki_trial/Reversion_collapsing
>

I think this could be done almost purely in Javascript. An extension or 
something would only need to add checksum of revisions to the page. The 
script would then collapse this onload. It could also collapse edits of 
the same user.

BTW. Wikia has something similar on recent changes. Not sure which 
extensions do they use.

Regards,
Nux.

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

Re: [Wikitech-l] ResourceLoader Debug Mode

[Maciej Jaros]

  Trevor Parscal wrote:
>There seems to be some confusion about how ResourceLoader works, which
> has been leading people to make commits like r73196 and report bugs like
> #25362. I would like to offer some clarification.
>
> ResourceLoader, if you aren't already aware, is a new system in
> MediaWiki 1.17 which allows developers to bundle collections of
> *resources* (like JavaScript and CSS files, or localized messages) into
> *modules*. Modules may represent any number of scripts, styles and
> messages, which are read from the file system, the database, or
> generated by software.
>
> When a request is made for one or more modules, each resource is
> packaged together and sent back to the client as a response. The way in
> which these requests and responses are performed depends on whether
> debug is on or off.
>
> When debug mode is off:
>
>  * Modules are requested in batches
>  * Resources are combined into modules
>  * Modules are combined into a response
>  * The response is minified
>
> When debug mode is on:
>
>  * Modules are requested individually
>  * Resources are combined into modules
>
> I think it's debatable whether debug=true mode goes far enough, since it
> still combines resources into modules, and I am open to contributions
> that can make debug=true mode even more debugging friendly by delivering
> the resources to the client as unchanged as possible. I also think it's
> debatable if debug=false mode goes far enough, since things like Google
> Closure Compiler have been proven to even further reduce the size of
> JavaScript resources, so I am also open to contributions which can make
> debug=false even more production friendly by improving front-end
> performance.
I might be a little tired but are you saying that debug mode does not 
preserve original line numbers? So this is debug mode as in "a bit 
easier to debug in Firebug then fully minified code"?

And I still don't see how minification options are evil. One "if" won't 
really change performance.

Regards,
Nux.

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

Re: [Wikitech-l] ResourceLoader Debug Mode

[Maciej Jaros]

  At 2010-09-30 20:35, Trevor Parscal wrote:
>>> [...]
>>> * Where end users report platform-specific JavaScript errors, it may
>>> be useful to be able to match the line number of the error with
>>> something meaningful.
>> The usefulness of this is attached to the idea the most important part
>> of the error message is the line number. In some browsers (such as many
>> versions of IE) the line numbers aren't even correct. Besides, as I have
>> said already, over and over, combination is going to throw off line
>> numbers anyways, not just making them higher, but depending on the
>> user's preferences they may be totally different from one user to
>> another. Line numbers in production mode (debug=false) are useless no
>> matter how much white-space is preserved.

To my experience something is better then nothing. IE (old one that is) 
is usually wrong when you have either long lines (ekhem ;-)) and have 
code inside script tags (instead of outer files). Picture this:

   1. A user says his browser reports an error.
   2. I ask for the browser and other stuff...
   3. I don't see the problem.
   4. He tries out debug mode and it's fine.
   5. I search through his code...

The problem with fully minified without any vertical white space code to 
me is that you cannot read this. Well I can't and Firebug can't and any 
other debugger AFAIK. If something comes up it will be almost impossible 
to catch.

>>> Since the cost of adding line breaks is fairly small, the contention
>>> was that it was a fair compromise between size and developer (and tech
>>> supporter) sanity. So I took those comments on board and implemented
>>> it shortly after the branch merge.
>> We should probably calculate just how small that cost is before we start
>> making asumptions based on it being "fairly small". Also, as I have been
>> saying, the production mode (debug=false) is only going to become more
>> optimized in the future, further reducing the value of line numbers.
> OK, now I've calculated it...
>
> On a normal page view with the Vector skin and the Vector extension
> turned on there's a 2KB difference. On an edit page with the Vector skin
> and Vector and WikiEditor extensions there's a 4KB difference.
>
> While adding 2KB to a request for a person in a remote corner of the
> world on a 56k modem will only add about 0.3 seconds to the download,
> sending 2,048 extra bytes to 350 million people each month increases our
> bandwidth by about 668 gigabytes a month. I don't know what that kind of
> bandwidth costs the foundation, but it's not free.

OK. It's not free, the question is it worth the effort and are you 
really calculating this correctly? I think it would be worth it as a 
just-in-case thing. Also JS is usually cached and actually get stuck in 
cache for days. And just to be sure - did you calculated gziped version 
difference or plain?

Plus developers will probably stick to debug mode if won't provide 
something in the middle. Yes, I can't speak for all, but personally I 
work on code (small tweaks) from time to time while I'm not doing other 
stuff in the minute. Always changing to debug mode to debug code will 
not be very productive to me. That's why I wrote my loader and I was 
hoping that you will add some stuff from it to the loader so I can use 
it and so the RL can be useful to me (in non-wikimedia use cases too).

Again I'm sure you are confident with your code and code of your 
colleagues and I'm not saying you screwed something up. I'm just saying 
something will eventually get screwed up just because it always does. 
That's why programmers are always needed isn't it ;-).

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

Re: [Wikitech-l] ResourceLoader Debug Mode

[Maciej Jaros]

  At 2010-09-30 23:13, Trevor Parscal wrote:
>On 9/30/10 1:55 PM, Maciej Jaros wrote:
>> At 2010-09-30 20:35, Trevor Parscal wrote:
>>>>> [...]
>>>>> * Where end users report platform-specific JavaScript errors, it may
>>>>> be useful to be able to match the line number of the error with
>>>>> something meaningful.
>>>> The usefulness of this is attached to the idea the most important part
>>>> of the error message is the line number. In some browsers (such as many
>>>> versions of IE) the line numbers aren't even correct. Besides, as I have
>>>> said already, over and over, combination is going to throw off line
>>>> numbers anyways, not just making them higher, but depending on the
>>>> user's preferences they may be totally different from one user to
>>>> another. Line numbers in production mode (debug=false) are useless no
>>>> matter how much white-space is preserved.
>> To my experience something is better then nothing. IE (old one that is)
>> is usually wrong when you have either long lines (ekhem ;-)) and have
>> code inside script tags (instead of outer files). Picture this:
>>
>>  1. A user says his browser reports an error.
>>  2. I ask for the browser and other stuff...
>>  3. I don't see the problem.
>>  4. He tries out debug mode and it's fine.
>>  5. I search through his code...
>>
>> The problem with fully minified without any vertical white space code to
>> me is that you cannot read this. Well I can't and Firebug can't and any
>> other debugger AFAIK. If something comes up it will be almost impossible
>> to catch.
>>
> There's this assumption here that when a bug is reported that a
> JavaScript developer is going to be lost without a line number. My
> experience is that when bugs are reported, the first step is
> reproduction, and then investigation. If we shouldn't be relying on
> users with little or no expertise to be participating in investigation.
> Also, error reporting with Firebug and most browsers is much more
> verbose than "error on line ##".

It's not an assumption. I AM one of the main developers working on bugs 
reported by users on pl.wiki. And yes line number is very helpful if 
accurate. Also note that I was picturing a situation where I have to 
debug the minified code when I don't get the error in my browser(s) at 
hand. Usually the problem is some extension/plug-in, but I can't tell 
unless I investigate. And reading minified code at it's current state is 
impossible for me.

I understand the need to minify code I really do. I just don't get it 
why do you want to minify this that much. HTML which is usually served 
at every page load is not minified. Further more even minified HTML can 
be readable for debuging purposes as every debugger (inspector) shows 
the structure of the code rather then a code pulp. Also why are there 
are explicitly added comments like "". People don't 
need comments and whitespace to read code, right? Also I have a PHP 
minifier if you are interested. Let's serve Mediawiki encode and if some 
developer want to debug the code he can always switch folders.

>> Plus developers will probably stick to debug mode if won't provide
>> something in the middle. Yes, I can't speak for all, but personally I
>> work on code (small tweaks) from time to time while I'm not doing other
>> stuff in the minute. Always changing to debug mode to debug code will
>> not be very productive to me. That's why I wrote my loader and I was
>> hoping that you will add some stuff from it to the loader so I can use
>> it and so the RL can be useful to me (in non-wikimedia use cases too).
> This is what debug mode is for. Developers. Developers should always use
> debug mode while debugging. Switching back and forth is not necessary
> for every tiny change, just a good thing to verify before checking in code.
>> Again I'm sure you are confident with your code and code of your
>> colleagues and I'm not saying you screwed something up. I'm just saying
>> something will eventually get screwed up just because it always does.
>> That's why programmers are always needed isn't it ;-).
>>
> It's not a matter of me thinking our code is so good it won't break.
> It's a matter of wanting to send fully optimized code to clients, not
> partially optimized code.
This is impossible. Fully optimized code would only contain one byte per 
variable name. Yo need to make sacrifices. And this seems to be needed 
as shown before and above.

> I 

Re: [Wikitech-l] ResourceLoader Debug Mode

[Maciej Jaros]

  At 2010-10-01 01:50, Trevor Parscal wrote:
>On 9/30/10 4:31 PM, Maciej Jaros wrote:
>> At 2010-09-30 23:13, Trevor Parscal wrote:
>>>  On 9/30/10 1:55 PM, Maciej Jaros wrote:
>>>>   At 2010-09-30 20:35, Trevor Parscal wrote:
>>>>>>> [...]
>>>>>>> * Where end users report platform-specific JavaScript errors, it may
>>>>>>> be useful to be able to match the line number of the error with
>>>>>>> something meaningful.
>>>>>> The usefulness of this is attached to the idea the most important part
>>>>>> of the error message is the line number. In some browsers (such as many
>>>>>> versions of IE) the line numbers aren't even correct. Besides, as I have
>>>>>> said already, over and over, combination is going to throw off line
>>>>>> numbers anyways, not just making them higher, but depending on the
>>>>>> user's preferences they may be totally different from one user to
>>>>>> another. Line numbers in production mode (debug=false) are useless no
>>>>>> matter how much white-space is preserved.
>>>> To my experience something is better then nothing. IE (old one that is)
>>>> is usually wrong when you have either long lines (ekhem ;-)) and have
>>>> code inside script tags (instead of outer files). Picture this:
>>>>
>>>>1. A user says his browser reports an error.
>>>>2. I ask for the browser and other stuff...
>>>>3. I don't see the problem.
>>>>4. He tries out debug mode and it's fine.
>>>>5. I search through his code...
>>>>
>>>> The problem with fully minified without any vertical white space code to
>>>> me is that you cannot read this. Well I can't and Firebug can't and any
>>>> other debugger AFAIK. If something comes up it will be almost impossible
>>>> to catch.
>>>>
>>> There's this assumption here that when a bug is reported that a
>>> JavaScript developer is going to be lost without a line number. My
>>> experience is that when bugs are reported, the first step is
>>> reproduction, and then investigation. If we shouldn't be relying on
>>> users with little or no expertise to be participating in investigation.
>>> Also, error reporting with Firebug and most browsers is much more
>>> verbose than "error on line ##".
>> It's not an assumption. I AM one of the main developers working on bugs
>> reported by users on pl.wiki. And yes line number is very helpful if
>> accurate. Also note that I was picturing a situation where I have to
>> debug the minified code when I don't get the error in my browser(s) at
>> hand. Usually the problem is some extension/plug-in, but I can't tell
>> unless I investigate. And reading minified code at it's current state is
>> impossible for me.
>>
> How can you possibly resolve an issue if you can't reproduce it?
> Developers have access to multiple browsers for this exact reason.
> Otherwise, you are debugging and programming blind, which is extremely
> unproductive.

I'm very productive with inspecting code with my eyes. Ask my boss ;-).

>> I understand the need to minify code I really do. I just don't get it
>> why do you want to minify this that much. HTML which is usually served
>> at every page load is not minified. Further more even minified HTML can
>> be readable for debuging purposes as every debugger (inspector) shows
>> the structure of the code rather then a code pulp. Also why are there
>> are explicitly added comments like "". People don't
>> need comments and whitespace to read code, right? Also I have a PHP
>> minifier if you are interested. Let's serve Mediawiki encode and if some
>> developer want to debug the code he can always switch folders.
>>
> I think that our outgoing HTML *should* be minified, and those comments
> should be stripped, I just have yet to get to that as of yet. Go to
> www.google.com and view source. Tell me what you see. Why are we so
> different from them? They are taking advantage of aggressive
> minification, and we should too.
>
> To be honest, I can't quite wrap my head around why I am getting any
> friction on making the front-end as fast as possible. I was expecting
> people to say I had not gone far enough.

Two reasons probably:
1. The gain is not big for average user (loading big JS is only painful 
at first visit in a 

Re: [Wikitech-l] MediaWiki.org's [[MediaWiki:Newarticletext]]

[Maciej Jaros]

  At 2010-10-10 10:02, Max Semenik wrote:
> On 10.10.2010, 6:36 Andrew wrote:
>
>> Do we seriously need such an obnoxious message here?
>> I realise that we might have had a problem in the past with people
>> clicking on the MediaWiki logo in the corner when installing their
>> wikis, but perhaps we could solve this problem by delinking it,
>> instead of an English Wikipedia style giant stop sign at the top of
>> the page. It really hurts my eyes.
> I must admit, the stop hand pic was added by me. The problem here is
> not that we need to delete crap - making several clicks is easy.
> However, people often spend significant amounts time writing a page
> intended for Wikipedia or their internal wiki only to see it deleted
> in a few minutes. That's not very nice either. And I must admit that
> the impact of my changes to the warning text was insignificant.

I think many people simply don't know how Internet works. When they run 
some standard application they stay in that application in the same 
window. And here you still are in the same window and if icons looks 
similar... I work for a company that makes applications for libraries. 
We made a new skin for readers catalogue and provide a default logo  of 
our company. Suddenly people started calling and asking if they can 
borrow book about "..." :-). Yes people adapt over time, but new ones 
must adapt this and new ones are born everyday.

> Total delinking would be strange, as this seems a stndard practice
> among other free web apps. And you can't seriously suggest that we
> remove mw.org links from the post-install message, too. There could be
> several other options:
> * Make mw.org look less alike to default installs. Changing skin to,
> say, Modern would be good, but our site must remain a showcase for our
> product, so we must stick to default look.
> * Change skins/common/images/wiki.png to not contain the MW logo.
> This will have only moderate effect, though.

Why not change the skin and create demo.wikimedia.org? That's what 
others do as usually the main page is not the showcase itself.

> * Create some kind of advanced protection, for example site JS that
> makes anons click on "continue" before seeing edit page. Not really an
> option in this particular way, but maybe something in this line could
> work. An extreme way to prevent many unwanted edits would be to
> restrict content page creation by anons, but I don't think we need it
> ATM.
That would be fairly easy to do with a simple confirm dialog run 
onsubmit (only added for anons). Or even lock edits add info (and a 
link) to either login or go to the demo site.

Regards,
Nux.

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

Re: [Wikitech-l] Vector extension naming

[Maciej Jaros]

  At 2010-10-13 05:10, Trevor Parscal wrote:
>On 10/12/10 8:03 PM, Chad wrote:
>> On Tue, Oct 12, 2010 at 10:45 PM, Trevor Parscal   
>> wrote:
>>>On 10/12/10 7:42 PM, MZMcBride wrote:
 Trevor Parscal wrote:
> Apologies in advance for the sheer triviality of this matter;
> unfortunately these kinds of bike shed problems [2] tend to be
> infinitely exciting, while complex matters are more often met with
> general disinterest.
>
> [1] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/73030#c10054
> [2] http://en.wikipedia.org/wiki/Parkinson%27s_Law_of_Triviality
 Naming and naming conventions aren't trivialities.

>>> Show me the convention for naming extensions and I will follow it. As
>>> long as there is none, spending time going back and forth discussing the
>>> name of something that users will never see is indeed spending time on a
>>> trivial matter.
>> There isn't one. Maybe it's because we haven't cared until now, or
>> maybe because we haven't needed it. Policy or not, concerns were
>> raised about the naming of *this* extension. Saying "well there's
>> no policy so it's pointless to discuss it" is a cop-out.
>>
> I am explicitly requesting discussion about it so that I can take action
> based on the desire of the community. What cop-out are you referring to?
>
> The only response I've gotten so far is "merge into core", which is an
> interesting response, but does not resolve the issue at hand, which is,
> until we do so (assuming we do at some point after 1.17), what should
> this extension be named?
>
> I'm not defending the current name any more than stating it's my
> preference. I'm not only open to naming it something else, but I'm
> asking for input on what to name it.
>
> Some people are being somewhat combatant or getting tangential in their
> responses - fine, basically what I expect form this list - but I'm still
> very interested in responses to do with my original question, "should we
> rename it, and if so, what should we name it?".

IF it should be renamed then I think it has to follow two rules:
1. Should be unique (should not collide with other people ideas)
2. Should tell you a bit about the extension.

In this case "Vector" is wrong. "Vector" might be an extension for SVG 
editing or something like that. To my understanding this extension is 
about usability of Vector skin and so it might be called VectorUsability 
or something more exact.

Having said that I also think Ryan Lane made a very valid point. 
Personally I'm still using the extension as part of "Usability 
Initiative" and if it is to be integrated into the core I'm not moving 
anywhere from that ;-).

Regards,
Nux.

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

Re: [Wikitech-l] Vector extension naming

[Maciej Jaros]

  At 2010-10-13 09:12, Roan Kattouw wrote:
> 2010/10/13 Trevor Parscal:
>> That's an entirely different discussion, and the results of that
>> discussion have so far been that any such action is being deferred until
>> after 1.17.
> With pretty much every participant in this thread (including myself,
> for the record) saying we should move these extensions into core ASAP
> (which I interpret to mean before 1.17), I think that statement is
> outdated at best. I realize you're hesitant to move Vector and
> WikiEditor into core, let alone do so before the 1.17 release, but I
> haven't seen anyone share that belief, and frankly I don't think any
> new commenters will.
>
> Let's just move Vector and WikiEditor into core soon and be done with it.

WikiEditor is a different thing at current stage. It breaks WYSIWYG made 
from FCKeditor and don't give anything important in exchange. Vector 
extension is ready to work while WikiEditor still needs a lot of work if 
you ask me.

Regards,
Nux.

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

Re: [Wikitech-l] ResourceLoader Debug Mode

[Maciej Jaros]

  @2010-10-22 00:53, Trevor Parscal:
>On 10/21/10 3:39 PM, Maciej Jaros wrote:
>> What about setting a cookie to go into a debug mode? I thought you liked
>> the idea?
>>
> I have no problem with that, it's just not implemented yet. Want to help?

Sure. I see new line characters are there, too. Cool!

Nux.

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

Re: [Wikitech-l] Commons ZIP file upload for admins

[Maciej Jaros]

@2010-10-26 03:45, Erik Moeller:
> 2010/10/25 Brion Vibber:
>> In all cases we have the worry that if we allow uploading those funky
>> formats, we'll either a) end up with malicious files or b) end up with lazy
>> people using and uploading non-free editing formats when we'd prefer them to
>> use freely editable formats. I'm not sure I like the idea of using admin
>> powers to control being able to upload those, though; bottlenecking content
>> reviews as a strict requirement can be problematic on its own.
> Yeah, I don't like the bottleneck approach either, but in the absence
> of better systems, it may be the best way to go as an immediate
> solution. We could do it for a list of whitelisted open formats that
> are requested by the community. And we'd see from usage which file
> types we need to prioritize proper support/security checks for.
>
>> What I'd probably like to see is a more wide-open allowal of arbitrary
>> 'source files' which can be uploaded as attachments to standalone files. We
>> could give them more limited access: download only, no inline viewing, only
>> allowed if DLs are on separate safe domain, etc.
> It seems fairly straightforward to me to say: "These free file formats
> are permitted to be uploaded. We haven't developed fully sophisticated
> security checks for them yet, so we're asking trusted users to do
> basic sanity checks until we've developed automatic checks." We can
> then prod people to convert any proprietary formats into free ones
> that are on that whitelist. And if they're free formats, I'm not sure
> why they shouldn't be first-class citizens -- as Michael mentioned,
> that makes it possible to plop in custom handlers at a later time. A
> COLLADA handler for 3D files may seem like a remote possibility, but
> it's certainly within the realm of sanity. ZIP files would have to be
> specially treated so they're only allowed if they contain only files
> in permitted formats.
>
> So, consistent with Michael's suggestion, we could define a
> 'restricted-upload' right, initially given to admins only but possibly
> expanded to other users, which would allow files from the "potentially
> insecure" list of extensions to be uploaded, and for ZIP files, would
> ensure that only accepted file types are contained within the archive.
> The resultant review bottleneck would simply be a reflection that we
> haven't gotten around to adding proper support for these file types
> yet. On the plus side, we could add restricted upload support for new
> open formats as soon as there's consensus to do so.
>
> The main downside I would see is that users might end up being
> confused why these files get uploaded. To mitigate this, we could add
> a "This file has a restricted filetype. Files of this type can
> currently only be uploaded by administrators for security reasons"
> note on file description pages.

ODS, ODT and such should be fairly easy to check at least on a basic 
level. A very basic check would be to check if it contains "Basic" or 
"Scripts" folder. Bit more advanced would be to check if manifest.xml 
contains "application/binary" (to check if anyone tried to change 
default naming) and check if any file contains "https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Skip local file description pages

[Maciej Jaros]

@2010-11-03 01:58, Lars Aronsson:
> Swedish Wikipedia has long ago disabled all local
> uploading of files (pictures) and has moved all files
> to Wikimedia Commons. When explaining Wikipedia and
> Commons to newcomers, it's very frustrating to land
> on the intermediary file description page on Wikipedia
> before moving on to Commons where image categories
> and other extra functions are found. To this end, a
> "gadget" has been installed in sv.wikipedia that changes
> all image links to point directly to Commons. This is
> very convenient, except that gadgets require a user
> account and a personal setting, so they are not
> available to the newcomers who need this.

If you already have a gadget just add it to [[MediaWiki:Common.js]] and 
disable the gadget by removing it from [[MediaWiki:Gadgets-definition]].

Regards,
Nux.

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

Re: [Wikitech-l] Resource Loader problem

[Maciej Jaros]

@2010-11-09 05:51, Jeroen De Dauw:
> Hey,
>
> Thanks again for the quick reply.
>
> The image paths appear to be correct when I view the file via that url. What
> I'm seeing when I load an OpenLayers map is that some of the controls that
> consist out of images get displayed as "firefox image not found" images, and
> then disappear from the map. I asked about this on the OpenLayers IRC and
> people there agreed it was most likely a CSS issue. So anyone an idea what
> might be going wrong here?

Background images in CSS files have paths relative to the CSS files. As 
Trevor said, those paths should be changed by RL, but probably something 
went wrong. To check to what path CSS points you can use Firebug (and 
point element with the image) or you can right click on the image and 
choose to copy image path (background image path in this case I guess). 
You might use non-relative paths (full URLs) to circumvent the problem.

Taking a wild guess here the problem might be because RL does not expect 
quotes around URL path. More URL variants here:
http://www.w3.org/TR/CSS2/syndata.html#value-def-uri

Best,
Nux.

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

Re: [Wikitech-l] Fwd: Re: [Mediawiki-l] vector components many blank lines

[Maciej Jaros]

@2010-12-09 05:25, Neil Kandalgaonkar:
> On 12/8/10 3:40 PM, Andrew Garrett wrote:
>> On Wed, Dec 8, 2010 at 3:11 AM, Trevor Parscalwrote:
>>> This particular change (the "don't delete line breaks" part of r73196)
>>> should be reverted, Tim's good changes should be pushed upstream, and we
>>> should be using a standard JSMin distribution whenever possible.
>> I think the point is that it makes bug reports that much easier to
>> understand when they're reported by somebody who isn't in debug mode. This
>> has to be traded off against the performance advantages of removing blank
>> lines. Is there any data on how significant the performance improvements
>> are?
> We already had this debate, in epic fashion, around September 30 - Oct
> 1st 2010.
>
> Rough estimates were traded, that suggested that these hacks to JSMin would
>
> - increase the total Javascript weight by 2KB;
> [...]
2KB with or without compression? AFAIR all calls were supposed to be gzipped 
and if gzip is not the lamest compressing method of all it will compress "\n" x 
30 in 2B and so having 30 whitespace or just one shouldn't really be that much 
of a difference.

Besides 2KB? Powered by MW icon is heavier. Just lowering colour depth to 16 
would save just as much. Changing two power icons into background + text + two 
small icons would probably save as much too.

Regards,
Nux.


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

Re: [Wikitech-l] A tool or web form for creating new pages

[Maciej Jaros]

@2010-12-15 00:12, Ben Schwartz:
> On 12/14/2010 05:40 PM, Platonides wrote:
>> Neil may be interested on this. He recently made the UploadWizard.
> I hadn't heard of this extension, but it looks interesting.  I presume
> it's not yet active on the actual Commons?

Recently activated:
http://commons.wikimedia.org/wiki/Special:UploadWizard

Regards,
Nux.

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

Re: [Wikitech-l] StringFunctions on enwiki?

[Maciej Jaros]

@2010-12-28 22:22, MZMcBride:
> Alex Brollo wrote:
>> I too don't understand precisely why string functions are so discouraged. I
>> saw extremely complex templates built just to do (with a high server load I
>> suppose in my ignorance...) what could be obtained with an extremely simple
>> string function.
> https://bugzilla.wikimedia.org/show_bug.cgi?id=6455#c92 (and subsequent
> comments)

I would say en wiki admins simply need to remove such abuse form things 
like:
http://en.wikipedia.org/w/index.php?title=Template:Asbox/templatepage&action=edit
This is just a quick example I found - maybe the category was needed at 
some point, but you can do the same working on a dump or with a bot and 
just get it done once.

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

Re: [Wikitech-l] How would you disrupt Wikipedia?

[Maciej Jaros]

2010-12-29 08:31, Neil Kandalgaonkar:
> I've been inspired by the discussion David Gerard and Brion Vibber
> kicked off, and I think they are headed in the right direction.
>
> But I just want to ask a separate, but related question.
>
> Let's imagine you wanted to start a rival to Wikipedia. Assume that you
> are motivated by money, and that venture capitalists promise you can be
> paid gazillions of dollars if you can do one, or many, of the following:
>
> 1 - Become a more attractive home to the WP editors. Get them to work on
> your content.
>
> 2 - Take the free content from WP, and use it in this new system. But
> make it much better, in a way Wikipedia can't match.
>
> 3 - Attract even more readers, or perhaps a niche group of
> super-passionate readers that you can use to build a new community.
>
> In other words, if you had no legacy, and just wanted to build something
> from zero, how would you go about creating an innovation that was
> disruptive to Wikipedia, in fact something that made Wikipedia look like
> Friendster or Myspace compared to Facebook?
>
> And there's a followup question to this -- but you're all smart people
> and can guess what it is.

If one would have a budget of gazillions of dollars then it would be 
quite easy ;-). The problem is - what would be the point of investing 
such money if you wouldn't get it back from this investment?

If you wouldn't have such money (mostly to pay users for creating 
content), then the most problematic part would be to convince community 
you are OK. IMHO this has nothing to do with usability or any such thing 
it's rather a matter of gaining trust. A part from that you would have 
to make all (or almost all) the things that work now work. If you would 
make a brand new software then you would have to rewrite at least most 
popular user scripts which would alone be a lot work. You would probably 
also have to make a nice WYSIWYG to make your site worth moving to. To 
make it worth to change at least some of user habits. Not to mention 
your site would need to build on a quikcly scalable infrastructure to 
guarantee high availabilty (at least as high as Wikipedia is).

In general, you have to remember that even if something is technically 
better it's not guaranteed to be successful. For example I think that DP 
(pgdp.net) and Rastko are technically better equiped for proofreading 
then Wikisource, but I guess for thoose already familiar with MediaWiki 
it's easier to create texts for Wikisource.

Regards,
Nux.

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

Re: [Wikitech-l] How would you disrupt Wikipedia?

[Maciej Jaros]

Bryan Tong Minh (2010-12-29 13:05):
> On Wed, Dec 29, 2010 at 12:36 PM, Maciej Jaros  wrote:
>> If one would have a budget of gazillions of dollars then it would be
>> quite easy ;-). The problem is - what would be the point of investing
>> such money if you wouldn't get it back from this investment?
>>
> While money can fix a lot of things, I don't think the current
> bottleneck is money. To break stuff you need to find community
> consensus, developer consensus, somebody willing to implement it and
> somebody to review it. Of course for a gazillion dollars you could
> perhaps the eliminate a few of these steps, but in general they are
> not really easy to solve with money I think.

Well if you would pay users for editing you could attract more users (at 
least those that are not willing to work for free). But I guess that 
would only work if you would have practically unlimited resources... 
Having said that I just remembered that Youtube works like that - you 
can get money if get a lot of viewers on your movies.

Regards,
Nux.

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

Re: [Wikitech-l] How would you disrupt Wikipedia?

[Maciej Jaros]

Neil Kandalgaonkar (2010-12-29 21:40):
> On 12/29/10 4:05 AM, Bryan Tong Minh wrote:
>> On Wed, Dec 29, 2010 at 12:36 PM, Maciej Jaros   wrote:
>>> If one would have a budget of gazillions of dollars then it would be
>>> quite easy ;-). The problem is - what would be the point of investing
>>> such money if you wouldn't get it back from this investment?
>>>
>> While money can fix a lot of things, I don't think the current
>> bottleneck is money.
> I apologize for sending this discussion in a direction I hadn't
> intended. The money was purely to imply that you had to be motivated,
> not that you had a vast budget.
>
> Let me be more explicit. The "innovator's dilemma" problem, already
> referred to in this discussion, occurs because the successful innovator
> can't see past the goal of defending their earlier successes, and
> working with their existing assets.
>
> The thought experiment of working for a competitor was meant to suggest
> this: what would you do if you wanted to make Wikipedia's earlier
> successes *obsolete*? The point is to then try to look at some of our
> greatest assets and see if, in the current environment, they could be
> potential liabilities.

My original point was that the community is the power of WMF sites and 
that this alone is IMHO hard to beat. To be more exact this is a 
community that I believe is loyal and needs to trust the 
corporation/founder/foundation behind the site (I've seen a community 
driven project fall after loosing this trust).

> And the followup question was "if a competitor can do this, why don't WE
> do this?"

We don't because it would probably be more reasonable for our competitor 
to do something completely different to gather different community or he 
would have to make a gigantic effort to steal current community (both in 
technical and PR terms). I think the effort would simply be inefficient.

In any case - the next killer functionality (if that's what you're 
asking) is well known and already mentioned - WYSIWYG. WYSIWYG that 
makes edits easy for new users and make them not break existing markup. 
And yes I believe present markup needs to be preserved. Not because it's 
good, it's because it is well know to many current users. It's because 
community is accustomed with it. Loosing users after changing markup 
drastically would certainly not be a good idea. You have to remember how 
many disappointment brought a simple change of default skin. Something 
that can be changed back in 3 clicks. And so new markup (if such would 
be used) would have to at least be parseable back to wikitext.

Regards,
Nux.

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

Re: [Wikitech-l] [Foundation-l] Big problem to solve: good WYSIWYG on WMF wikis

[Maciej Jaros]

masti (2010-12-31 01:33):
> On 12/31/2010 01:19 AM, Platonides wrote:
>> masti wrote:
 That is true - "We can't do away with Wikitext" always been the
 intermediate conclusion (in between "My god, we need to do something
 about this problem" and "This is hopeless, we give up again").

>>> between wikitext and WYSISWYG is a simple solution of colourizing text
>>> like for hundreds of programing (and otehr) languages formats in a
>>> simple text editor. This is not a rocket science but we still do not
>>> have it :(
>>>
>>> masti
>> Have you tried wikiEd ?
> yes :(
>
> why not have this functionality in wikiedit window?

Because wikEd is wicked ;-) and spoils simple editor window so that many 
other scripts have problems using it. Also probably because it's not 
really helpful for all users to work with and certainly is making your 
computer work slower.

Regards,
Nux.

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

Re: [Wikitech-l] WYSIFTW status

[Maciej Jaros]

Aryeh Gregor (2011-01-17 17:31):
> On Sun, Jan 16, 2011 at 7:16 PM, Magnus Manske
>   wrote:
>> There is the question of what browsers/versions to test for. Should I
>> invest large amounts of time optimising performance in Firefox 3, when
>> FF4 will probably be released before WYSIFTW, and everyone and their
>> cousin upgrades?
> Design for only the fastest browsers.  Other browsers could always
> just be dropped back to the old-fashioned editor.

+1
IMHO on some later stage (after optimizing and testing) you should think 
about quickly dropping to either simple version of the editor (e.g. only 
folding ref) or to the plain textarea version. Also old versions of 
browser might benefit a lot by not using jQuery too much (IIRC Google JS 
engine was the first to be optimized for frameworks like jQuery and that 
is why it behaves better). Maybe also some hint for users might be given 
that their browser/machine is too slow for more advanced editor on whole 
page and that they might want to edit a single section...

Regards,
Nux

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

Re: [Wikitech-l] Category sorting and first letters

[Maciej Jaros]

Tim Starling (2011-01-18 02:03):
> On 18/01/11 07:41, Amir E. Aharoni wrote:
>> 2011/1/17 Tim Starling:
>>> * It automatically drops accents, since accented letters sort the same
>>> as unaccented letters (at the primary level).
>> How locale aware is it? For example, in Swedish accented letters come
>> at the end of the alphabet and in Lithuanian I, Į and Y are collated
>> together as if they were one letter. There are many quirks of this
>> kind in other languages.
> It's not locale-aware. As I said, it's a compromise collation. I was
> hoping that other people might be interested in adding support for
> specific locales, that's part of the reason for my post. ICU supports
> lots of different locales, and there is locale-specific collation data
> in the CLDR.
>
>> And i don't know what to do when in the Lithuanian Wikipedia you sort
>> names of places in the UK - should Islington come before or after
>> York?
> Before.
>
>> $collator = new Collator('lt')
>> print $collator->compare( 'Islington', 'York' )
> -1
>
> But more interestingly, York goes before London:
>
>> print $collator->compare( 'York', 'London' )
> -1
>
> I think attempting to do it any other way would be a lot of trouble,
> and not what is wanted anyway. To put the question another way: on the
> English Wikipedia, should Kybartai sort before Klaipėda? I would think
> not.

I've seen sorting accent insensitive and so for example "Bańka" would be 
sorted as if it was "Banka", but I haven't yet seen phone insensitive or 
whatever you call it. What I mean is in Poland "rz" i pronounced the 
same (almost the same) as "ż", but "rz" is nowhere near "ż" when it 
comes to sorting. In fact it would be very counter intuitive for me (as 
would be 'York' < 'London'). I think it would not be helpful especially 
for foreigners. I've also said that I've _seen_ accent insensitive 
dictionaries, but _most_ are case sensitive and so "ą" > "a" not "ą"="a" 
also when it comes to the first letter all dictionaries I know have "Ż" 
separate from "Z". You might see our collation as - without accent first 
and with accent second. This is the why we say are ABC. And it would be 
intuitive for to have English collation by it's ABC with Y coming just 
before Z.

I think the problem should only be solved for letters which are not just 
Latin character + accent. How to sort them in Latin (and Latin based) 
characters.

Regards,
Nux.


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

Re: [Wikitech-l] Category sorting and first letters

[Maciej Jaros]

Maciej Jaros (2011-01-18 15:42):
> Tim Starling (2011-01-18 02:03):
>> On 18/01/11 07:41, Amir E. Aharoni wrote:
>>> 2011/1/17 Tim Starling:
>>>> * It automatically drops accents, since accented letters sort the same
>>>> as unaccented letters (at the primary level).
>>> How locale aware is it? For example, in Swedish accented letters come
>>> at the end of the alphabet and in Lithuanian I, Į and Y are collated
>>> together as if they were one letter. There are many quirks of this
>>> kind in other languages.
>> It's not locale-aware. As I said, it's a compromise collation. I was
>> hoping that other people might be interested in adding support for
>> specific locales, that's part of the reason for my post. ICU supports
>> lots of different locales, and there is locale-specific collation data
>> in the CLDR.
>>
>>> And i don't know what to do when in the Lithuanian Wikipedia you sort
>>> names of places in the UK - should Islington come before or after
>>> York?
>> Before.
>>
>>> $collator = new Collator('lt')
>>> print $collator->compare( 'Islington', 'York' )
>> -1
>>
>> But more interestingly, York goes before London:
>>
>>> print $collator->compare( 'York', 'London' )
>> -1
>>
>> I think attempting to do it any other way would be a lot of trouble,
>> and not what is wanted anyway. To put the question another way: on the
>> English Wikipedia, should Kybartai sort before Klaipėda? I would think
>> not.
> I've seen sorting accent insensitive and so for example "Bańka" would be
> sorted as if it was "Banka", but I haven't yet seen phone insensitive or
> whatever you call it. What I mean is in Poland "rz" is pronounced the
> same (almost the same) as "ż", but "rz" is nowhere near "ż" when it
> comes to sorting. In fact it would be very counter intuitive for me (as
> would be 'York'<  'London'). I think it would not be helpful especially
> for foreigners. I've also said that I've _seen_ accent insensitive
> dictionaries, but _most_ are case sensitive and so "ą">  "a" not "ą"="a"
> also when it comes to the first letter all dictionaries I know have "Ż"
> separate from "Z". You might see our collation as - without accent first
> and with accent second. /This is the why we say are ABC. And it would be
> intuitive for to have English collation by it's ABC with Y coming just
> before Z./

Sorry, sometimes I type phonetically :-). The last sentences were 
supposed to be:

This is the way we say our ABC. And it would be intuitive for me to have 
English collation by its ABC with Y coming just before Z.


> I think the problem should only be solved for letters which are not just
> Latin character + accent. How to sort them in Latin (and Latin based)
> characters.
>
> Regards,
> Nux.
>
>
> ___
> 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] Farewell JSMin, Hello JavaScriptDistiller!

[Maciej Jaros]

Trevor Parscal (2011-01-20 23:13):
> For those of you who didn't see bug 26791, our use of JSMin has been
> found to conflict with our GPL license. After assessing other options (
> https://bugzilla.wikimedia.org/show_bug.cgi?id=26791#c8 ) Roan and I
> decided to try and use the minification from JavaScriptPacker, but not
> its overly clever but generally useless packing techniques. The result
> is a minifier that outperforms our current minifier in both how quickly
> it can minify data and how small the minified output is.
> JavaScriptDistiller, as I sort of randomly named it, minifies JavaScript
> code at about 2x the speed of Tim's optimized version of JSMin, and 4x
> the speed of the next fastest PHP port of JSMin (which is generally
> considered the standard distribution).
>
> Similar to Tim's modified version of JSMin, we chose to retain vertical
> whitespace by default. However we chose not to retain multiple
> consecutive empty new lines, which are primarily seen where a large
> comment block has been removed. We feel there is merit to the argument
> that appx. 1% bloat is a reasonable price to pay for making it easier to
> read production code, since leaving each statement on a line by itself
> improves readability and users will be more likely to be able to report
> problems that are actionable. We do not however find the preservation of
> line numbers of any value, since in production mode most requests are
> for many modules which are concatenated, making line numbers for most of
> the code useless anyways.
>
> This is a breakdown based on "ext.vector.simpleSearch"
>
> * 3217 bytes (1300 compressed)
> * 2178 bytes (944) after running it through the version of JSMin that
> was in our repository. Tim modified JSMin to be faster and preserve line
> numbers by leaving behind all vertical whitespace.
> * 2160 bytes (938 compressed) after running it through
> JavaScriptDistiller, which applies aggressive horizontal minification
> plus collapsing multiple consecutive new lines into a single new line.
> * 2077 bytes (923 compressed) after running it through
> JavaScriptDistiller with the vertical space option set to true, which
> applies aggressive horizontal minification as well as some basic
> vertical minification. This option is activated through
> $wgResourceLoaderMinifyJSVerticalSpace, which is false by default.

Yes, I know I'm stubborn, but 6 bytes (0.6%)? Seriously? Doesn't seem 
convincing to me and seems like it could at least use 
$wgResourceLoaderMinifyJSHorizontalSpace (even if true by default).

Regards,
Nux.

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

Re: [Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller!

[Maciej Jaros]

Roan Kattouw (2011-01-21 00:50):
> 2011/1/21 Maciej Jaros:
>> Yes, I know I'm stubborn, but 6 bytes (0.6%)? Seriously? Doesn't seem
>> convincing to me and seems like it could at least use
>> $wgResourceLoaderMinifyJSHorizontalSpace (even if true by default).
>>
> Trevor probably didn't choose a very good test case. He also tested it
> on jQuery, though, and found that the unmodified version of JSPacker
> was faster than JSMin and produced output that was 1% larger after
> gzip. So in the general case, JSDistiller probably doesn't quite
> minify JS optimally, but the difference with JSMin is small and the
> difference in performance is ridiculous. That, and it doesn't present
> legal problems.

You've misunderstood me. As long as it's well tested and performs nicely 
then I'm all for (though I don't remember using MediaWiki for Evil ;-)). 
Great job, really. I was only hoping to have an option to fully preserve 
vertical space, but I've made a rotation in the name :-). So the option 
could be $wgResourceLoaderMinifyJSVerticalSpacePreserved or maybe 
$wgResourceLoaderMinifyJSPreserveEmptyLines.

Regards,
Nux.

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

Re: [Wikitech-l] Farewell JSMin, Hello JavaScriptDistiller!

[Maciej Jaros]

Michael Dale (2011-01-21 16:04):
> On 01/21/2011 08:21 AM, Chad wrote:
>> While I happen to think the licensing issue is rather bogus and
>> doesn't really affect us, I'm glad to see it resolved. It outperforms
>> our current solution and keeps the same behavior. Plus as a bonus,
>> the vertical line smushing is configurable so if we want to argue
>> about \n a year from now, we can :)
> Ideally we will be using closures by then and since it rewrites
> functions, variable names and sometimes collapses multi-line
> functionality, new line preservation will be a mute point. Furthermore,
> Google even has a nice add-on to firebug [1] for source code mapping.
> Making the dead horse even more dead.
>
> I feel like we are suck back in time, arguing about optimising code that
> came out eons ago in net time ( more than 7 years ago ) There are more
> modern solutions that take into consideration these concerns and do a
> better job at it. ( ie not just a readable line but a pointer back to
> the line of source code that is of concern )
>
> [1] http://code.google.com/closure/compiler/docs/inspector.html

Great. Now I only need to tell the user to install Firefox, install 
Firebug and some other addon, open the page in Firefox... Oh, wait. This 
error does not occur in Firefox...

Please, I can live with folding new lines (thou I don't believe those 
few bites are worth it) acutely compiling the code (or packing as some 
say) would be just evil for Mediawiki or Wikimedia to be more exact.

Just remember that people all over the world are hacking into Mediawiki 
all the time. Making it harder won't help a bit.

Regards,
Nux.

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

Re: [Wikitech-l] user email validation ready

[Maciej Jaros]

Brion Vibber (2011-01-25 02:51):
> On Mon, Jan 24, 2011 at 4:02 PM, Platonides  wrote:
>
>> The original spec had feedback based precisely on enwiki numbers.
>> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-August/00.html
>>
>> So about 100? Note that there are invalid addresses marked as confirmed
>> in wikipedia.
>>
> Ok so from the breakdown at
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-August/022237.html
> with 202 email address records that were marked as confirmed, but failed
> the proposed validation check at the time and couldn't be corrected by 
> stripping
> whitespace:
> [...]

Could you check for validated address containing commas in user names 
part? The RegExp from mediawiki.util.js did/does allow them.

Regards,
Nux.

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

Re: [Wikitech-l] Re sourceLoader + Windows + PHP bug 47689

[Maciej Jaros]

Ilmari Karonen (2011-01-30 15:19):
> On 01/30/2011 04:16 PM, Platonides wrote:
>> Ilmari Karonen wrote:
>>> Hmm... I don't really know what's going on inside PHP's PCRE
>>> implementation, but you might want to try replacing that regexp with:
>>>
>>>  $parser->add( '/\\/\\*.*?\\*\\//s' );
>> The add()s are combined into a single big regex, you can't set dot-all.
>> Doing it with (?s) may be factible, though.
> Hmm, so maybe:
>
> $parser->add( '/(?s:\\/\\*.*?\\*\\/)/' );
>
> Or if that doesn't work, try something else that matches everything
> without parens, like [\s\S] or [\d\D].

Personally I like the [\s\S] construct, but maybe adding ?: in the 
parentheses would work:

> $parser->add( '/\\/\\*(?:.|[\\r\\n])*?\\*\\//' );

Just guessing, but maybe the problem occurred because the script was 
trying to catch something in them...

Cheers,
Nux.

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

Re: [Wikitech-l] Planned 1.17 deployment on February 8

[Maciej Jaros]

Roan Kattouw (2011-02-01 10:14):
> 2011/2/1 Rob Lanphier:
>>> Can you explain why you're rolling out when it's the middle of the night
>>> where Wikimedia is headquartered? I have a few different theories (site
>>> traffic, time zones of the operations team, etc.), but a clarification here
>>> would be good.
>>
>> We lost the game of rock/paper/scissors.  :)  We decided to do this very
>> late U.S. west coast time so that our European and Australian contingents
>> would be well rested in case there are problems.  Given that we have key
>> personnel pretty much all over the globe, there wasn't going to be a great
>> time for this, and this has the added advantage of being a relatively low
>> traffic time for us.
>>
> Look at http://torrus.wikimedia.org/torrus/CDN?path=%2FTotals%2F and
> you'll see that, for the past two days, the time of lowest traffic was
> between 06:00 and 07:00 UTC. This has been a quite reliable pattern
> for quite some time now (except that it shifts by an hour in Northern
> Hemisphere summer, due to DST), and we've also used this time for the
> first few Vector deployments.
>
> [...]

Can you set a different deploy date for different projects? E.g. 18.00 
UTC for Poland. I will not be able to be there when hell will brake 
loose as I will be working and I'm sure most of the Polish tech admins 
will be too. Note that we was able test Vector with current scripts 
before the deploment so this is a bit different. And I still remember 
the ammount of complaints bouncing here and there when Vector came and 
broke Wikipedia and what not... Not that they were all valid and could 
have been avoided, but maybe some could.

Not that I'm complaining ;-), but prototype is... well it's empty for 
now and it would be good if we could test scripts and do it as fast (and 
as soon) as possible. I've already asked Leinad, but maybe someone could 
import current Mediawiki namespace to prototype quicker.

For one thing - I think our script for moving the search bar to the left 
side panel will be probably broken (as you make it wider now) and this 
will probably have to be fixed right after deployment...

Regards,
Nux.

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

Re: [Wikitech-l] Planned 1.17 deployment on February 8

[Maciej Jaros]

Chad (2011-02-03 20:52):
> On Thu, Feb 3, 2011 at 2:48 PM, Maciej Jaros  wrote:
>> Can you set a different deploy date for different projects? E.g. 18.00
>> UTC for Poland.
>>
> Not easily. As a general rule all software goes to all sites at the same
> time.

How hard is not easily? :-)

>> I will not be able to be there when hell will brake
>> loose as I will be working and I'm sure most of the Polish tech admins
>> will be too.
>>
> Well luckily none of you need to be there for this ;-) This is a normal
> software deployment of the latest fixes and features. There's nothing
> special or different about this one from the dozens that have happened
> over the years.

Theoretically you're right ;-). But to my knowledge RL is in this 
release and this make this release almost as special as making Vector 
default. And Vector was easier because we were able to test it live with 
our scripts. But maybe I'm just superstitious ;-).

Cheers,
Nux.

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

Re: [Wikitech-l] Planned 1.17 deployment on February 8

[Maciej Jaros]

Platonides (2011-02-03 21:53):
> Maciej Jaros wrote:
>> Can you set a different deploy date for different projects? E.g. 18.00
>> UTC for Poland. I will not be able to be there when hell will brake
>> loose as I will be working and I'm sure most of the Polish tech admins
>> will be too. Note that we was able test Vector with current scripts
>> before the deploment so this is a bit different. And I still remember
>> the ammount of complaints bouncing here and there when Vector came and
>> broke Wikipedia and what not... Not that they were all valid and could
>> have been avoided, but maybe some could.
>>
>> Not that I'm complaining ;-), but prototype is... well it's empty for
>> now and it would be good if we could test scripts and do it as fast (and
>> as soon) as possible. I've already asked Leinad, but maybe someone could
>> import current Mediawiki namespace to prototype quicker.
>>
>> For one thing - I think our script for moving the search bar to the left
>> side panel will be probably broken (as you make it wider now) and this
>> will probably have to be fixed right after deployment...
>>
>> Regards,
>> Nux.
> You could also test the scripts in advance. If you think a particular
> script will break/need to be disabled with the switchover, you can
> always warp it in a if (wgVersion=="1.16wmf4") { check.
> That kind of action shouldn't be needed, though.

Hm... Not a bad idea.

> I don't see that plwiki have its search bar at the left sidebar, I don't
> know what does that script.

You can switch with a link at the top of the page (in p-personal) on the 
left. It stays that way thanks to the cookie setting and you don't have 
to be logged in... Just a little something I've done for those wanting 
to go back a bit to monobook but not all the way ;-). I can already see 
it's broken on prototype (we now have MediaWiki imported) but that's an 
easy fix with that wgVersion hack.

Cheers,
Nux.

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

Re: [Wikitech-l] Fwd: [Gendergap] Fwd: Gender preference

[Maciej Jaros]

Daniel ~ Leinad (2011-02-11 15:14):
>> Amir left a comment saying that the User: namespace in Russian is
>> translated into the equivalent of User_male: (I guess if the user set
>> male in the preferences as gender) and User_female: (if female in the
>> preferences).
>> Do you know if this happens in other wikipedia as well?
> Polish, Czech, Russian Wikipedias have alias in feminine form (source:
> http://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php)
> - it means that also males can use female alias, for example
> http://pl.wikipedia.org/wiki/Wikipedystka:Leinad (female alias) =>
> http://pl.wikipedia.org/wiki/Wikipedysta:Leinad (regular namespace in
> masculine form).
>
> And as I said a few posts ago about bugs
>   we are waiting
> on regular namespace for females (configurable via Preferences) - now
> it is not possible.
>

Just to clarify - there is no separate namespace but the tabs do change 
after setting up preferences. You can do this by changing 
MediaWiki:Nstab-user to something like:
{{GENDER:{{BASEPAGENAME}}|Male|Female|Just human ;-)}}

Cheers,
Nux.

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

Re: [Wikitech-l] Simple Search Simplification

[Maciej Jaros]

+1 to both, looks to much like another tab and it does something 
completely different. Different things should look differently. Might be 
even more confusing if the drop down menu arrow would be on the left of 
it (then that's usually visible when you log in) - would suggest a 
search history button or something like that.

Brandon Harris (2011-02-15 04:05):
>   I agree.  I think that the search box needs to be distinct and obvious
> as a control; this change blends it into the background too much.
>
>   Since search is one of our most important features, it should stand out
> and be easier to target visually, not less.
>
>
> On 2/14/11 6:27 PM, Chad wrote:
>> On Mon, Feb 14, 2011 at 7:27 PM, Trevor Parscal   
>> wrote:
>>> I was working on fixing 
>>> https://bugzilla.wikimedia.org/show_bug.cgi?id=27332 (resolved in r82155) 
>>> and started messing with removing most of the gratuitous lines in the 
>>> search UI. Here's a screenshot of what we could do instead.
>>>
>> I don't like it really :-\ I like having the space around the box.
>> It helps set it out from the rest of the bar. With your changes,
>> it kind of blurs the distinction, at least to me. I'm just one
>> opinion though, and by my own account suck at everything
>> related to making a UI.
>>
>> -Chad
>>
>> ___
>> 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
>
>


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

Re: [Wikitech-l] Recommendation to revert "global login" checkbox from CentralAuth login form

[Maciej Jaros]

Chad (2011-02-17 01:52):
> On Wed, Feb 16, 2011 at 7:46 PM, Brion Vibber  wrote:
>> If there's no strong objection, I'd like to revert it. If there really is
>> some very specific need for non-global logins (wtf?!) this should be
>> something that individual people who really need it can *get to* with their
>> secret wizard knowledge but not inflict on everyone else. ;)
>>
> I'm fine with reverting this out of the login UI. I imagine it's only
> going to cause more confusion than anything for innocent users
> who don't really know what they're clicking. "Log me in globally?
> I just want to login to Wikipedia!"
>
> I can see the usefulness in skipping the global login for debugging
> or for some other freaky edge case a power user might come up
> with. How about as a compromise, we make the feature available
> through a query parameter or the API?
>
> If nobody has a really solid use case though, I'm fine with outright
> removal too.

Maybe this would do:
#mw-centralauth-login {display: none}

That way one can use Greasmonkey or some user CSS in a browser to show it.

Cheers,
Nux.

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

[Wikitech-l] Gantt extension for MediaWiki

[Maciej Jaros]

Hi.

I'm getting close to releasing JSWikiGantt extension and I'm wondering 
if this should go to SVN or not? And in effect should I ask for commit 
access to SVN or not. I have my own server so I can put my code there, 
but I'm not sure what are the habits with extensions.

Just to clarify what the extension is - it's basically a port of JSGantt 
to MediaWiki. It allows injecting Gantt diagrams as XML into articles. 
There's certainly a lot room for improvement (like e.g. an ability to 
have more then one diagram per page) and I still need to go for i18n, 
but that should be ready soon (I hope).

BTW are there any guidelines (or at least good examples) of i18n in JS? 
What I mean is - I need to use some (most) localized strings in JS and 
would like to use existing code (if possible) for pushing strings from 
PHP to JS.

I also have another extension for editing diagrams of certain type - 
namely calendar-diagrams for activities such as "Delegation", 
"Vacation", "Sick leave". From what I've read this probably shouldn't go 
to SVN or should it?

Oh, both extensions where written for 1.16, but I'm mostly using JS 
anyway so this probably shouldn't matter.

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

Re: [Wikitech-l] Gantt extension for MediaWiki

[Maciej Jaros]

Roan Kattouw (2011-04-14 13:30):
> 2011/4/14 Maciej Jaros:
>> BTW are there any guidelines (or at least good examples) of i18n in JS?
>> What I mean is - I need to use some (most) localized strings in JS and
>> would like to use existing code (if possible) for pushing strings from
>> PHP to JS
> [snip]
>> Oh, both extensions where written for 1.16, but I'm mostly using JS
>> anyway so this probably shouldn't matter.
> Use ResourceLoader, which handles i18n for you. ResourceLoader is new
> in 1.17 though, so code written with ResourceLoader will not work with
> 1.16 unless you go out of your way to make it dual-compatible.
>
> See 
> https://secure.wikimedia.org/wikipedia/mediawiki/wiki/ResourceLoader/Documentation/Using_with_extensions

Sadly not an option for me. It must work on 1.16 as I cannot upgrade 
office wiki to 1.17 (some extensions like e.g. WYSWIG don't work there). 
Is there some more or less standard way to do it for 1.16?

BTW [[mw:Localisation]] is missing that info.

Regards,
Nux.

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

Re: [Wikitech-l] Gantt extension for MediaWiki

[Maciej Jaros]

Roan Kattouw (2011-04-14 13:30):
> 2011/4/14 Maciej Jaros:
>> BTW are there any guidelines (or at least good examples) of i18n in JS?
>> What I mean is - I need to use some (most) localized strings in JS and
>> would like to use existing code (if possible) for pushing strings from
>> PHP to JS
> [snip]
>> Oh, both extensions where written for 1.16, but I'm mostly using JS
>> anyway so this probably shouldn't matter.
> Use ResourceLoader, which handles i18n for you. ResourceLoader is new
> in 1.17 though, so code written with ResourceLoader will not work with
> 1.16 unless you go out of your way to make it dual-compatible.
>
> See 
> https://secure.wikimedia.org/wikipedia/mediawiki/wiki/ResourceLoader/Documentation/Using_with_extensions

Sadly not an option for me. It must work on 1.16 as I cannot upgrade 
office wiki to 1.17 (some extensions like e.g. WYSWIG don't work there). 
Is there some more or less standard way to do it for 1.16?

BTW [[mw:Localisation]] is missing that info.

Regards,
Nux.

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

Re: [Wikitech-l] Gantt extension for MediaWiki

[Maciej Jaros]

Maciej Jaros (2011-04-14 16:03):
> Roan Kattouw (2011-04-14 13:30):
>> 2011/4/14 Maciej Jaros:
>>> BTW are there any guidelines (or at least good examples) of i18n in JS?
>>> What I mean is - I need to use some (most) localized strings in JS and
>>> would like to use existing code (if possible) for pushing strings from
>>> PHP to JS
>> [snip]
>>> Oh, both extensions where written for 1.16, but I'm mostly using JS
>>> anyway so this probably shouldn't matter.
>> Use ResourceLoader, which handles i18n for you. ResourceLoader is new
>> in 1.17 though, so code written with ResourceLoader will not work with
>> 1.16 unless you go out of your way to make it dual-compatible.
>>
>> See 
>> https://secure.wikimedia.org/wikipedia/mediawiki/wiki/ResourceLoader/Documentation/Using_with_extensions
> Sadly not an option for me. It must work on 1.16 as I cannot upgrade
> office wiki to 1.17 (some extensions like e.g. WYSWIG don't work there).
> Is there some more or less standard way to do it for 1.16?
>
> BTW [[mw:Localisation]] is missing that info.
>
> Regards,
> Nux.

Never mind. Found it in CategoryTree if anyone would be looking for it...

Cheers,
Nux.

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

Re: [Wikitech-l] Visual editor collaboration

[Maciej Jaros]

Mihály Héder (2011-12-17 14:46):
> Hello,
>
> Congratulations on LocalWiki, that is really great!
> In HTML5 editor category you should check out Aloha Editor as well:
> http://aloha-editor.org
>
> My favorite demos:
> http://aloha-editor.org/demos/css3/ (*everyone* should check out this one!
> Of course its useless but fun :)
> http://aloha-editor.org/demos/wordpress-demo/
> http://aloha-editor.org/demos/960-fluid-demo/
>
> I've just started to study their plugin system, which looks promising. My
> painful experience with TinyMCE and other RTE-s and also with the old wiki
> editor is that if you cannot make your custom stuff fit in a standard
> plugin (which is too often the case), it will be very hard to upgrade
> later. So IMO if you go for future-proofness you should check the
> customization options.
Not a good editor for wide colaboration:
if(...||jQuery.browser.opera){alert("Sorry, your browser is not 
supported at the moment.");return}

Regards,
Nux.


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

Re: [Wikitech-l] VisualEditor link-activating/following

[Maciej Jaros]

Kaseluris-Nikos-1959 (2011-12-18 05:19):
> The processes|actions on links we deal-with are:
> 1) in a browser: a) link activating.
> 2) in a source-editor: a) link-text editing, b) link-target editing.
> 3) in a wysiwyg-editor: a) link-text editing, b) link-target editing
> c) link activating|following.
>
> In VisualEditor (wysiwyg) link-activation is not yet implemented. So
> far I have seen 3 methods for this:
> i) double clicking
> ii) ctrl + clicking
> iii) popup the target, where you can activate the link.
>
> I am using everyday a local hypertext wysiwyg editor for 20 years now
> (yes before html!!!) which uses the double-click method. I vote for
> this as the fastest and using only one hand.
>
> I would like to here the VisualEditor's team opinions.
>
I think you should add this to bugzilla, but I would vote for 
CTRL+click. I feel this is the most common way now (Open/MS office apps 
and CK editor use this). In any case hoverning a link should display 
information on how you can go to the link.

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

Re: [Wikitech-l] Mass changes to bugs by Jan Kucera (Kozuch)

[Maciej Jaros]

Thehelpfulone Wikipedia (2011-12-30 21:03):
> If you vote for a bug then you are automatically added to the CC list and you 
> it's a nice way to keep track of the bugs you are interested in using 'My 
> Votes'. However, at first when I saw the votes system, I too believed that 
> more votes = more quickly done. As this is not the case, removing votes might 
> be a good way forward.

For me its simple: If voting is note used then it should be removed. If 
it stays it should be used. I too was confused that it is used as it is 
available.

Mozilla says you shouldn't comment on bugs only to say "please fix it" - 
you should vote instead. In my work we keep truck of how many clients 
wants the bug to get fixed (you might say - vote for a bug). The more 
people vote for a bug the more severe the bug is then you might think at 
first. The more severe the bug is the more probable it is to be pushed 
into the next version. And priority is more or less - how fast this 
should be done when working on a new version (which is mostly a 
developer preference).

Regards,
Nux.

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

Re: [Wikitech-l] Files with unknown copyright status on MediaWiki wiki

[Maciej Jaros]

K. Peachey (2011-12-31 11:25):
> We currently have a large number of file uploads with no licensing
> data on MW wiki! And we should really start doing something about it,
> As some people may have noticed last week(ish) I went though and tag
> most (if not all) of the uploads from this year that didn't have the
> licensing data. The current figures stand at:
>
> * Tagged as being from this year  : 182
> * From "Cat:Files with unknown copyright status"  :  28 (Minus this years)
> * From "Cat:Images with unknown copyright status" :  66
>   TOTAL TAGGED : 276 Files
>

This is probably because of UploadWizard - I was recently uploading a 
file which was based on other file from Commons and there was no way too 
choose the correct licence (PD). I had to change it afterwards. Also 
category wasn't added to page although I did add it. I wasn't sure it 
would reproducible and didn't reported it.

Most people probably won't notice such things as UploadWizard gives you 
the code to paste to wiki in the process and so you don't even see the 
image page.

Cheers,
Nux.

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

[Wikitech-l] JSGantt inside wiki articles

[Maciej Jaros]

Hi.

I faintly remember someone mentioned Gantt diagrams/charts here so here 
it is:
http://www.mediawiki.org/wiki/Extension:JSWikiGantt
I must warn you that if you want to look at the code, please close your 
eyes when you look at jsgantt.js ;-). This must have been a fun project 
some years ago (there are some really interesting concepts there), but 
is rather hard in modifying e.g. to allow more then one diagram per 
page. I'll probably rewrite this someday. I was thinking about either 
rendering this to SVG or on canvas rather then plain HTML. Any thoughts 
on that?

We use this extension at work to plan/visualize small development 
sprints by exporting tasks from Flyspray to Gantt XML. This is a bit 
specific as Flyspray doesn't really have time interval field but I could 
probably share this code if anyone wanted.

And here is an extension that uses Gantt for something a bit different:
http://www.mediawiki.org/wiki/Extension:JobSchEd

We use this to build something that on might call an out of office schedule.

Technically this extension is actually just a JavaScript that gets build 
dynamically from JS modules by PHP and included in the header. Could 
probably be used more generally, but as RL is now in 1.17 then this is 
probably a bit less useful then it was.

Cheers,
Nux.

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

Re: [Wikitech-l] JSGantt inside wiki articles

[Maciej Jaros]

Brion Vibber (2011-06-11 23:23):
> On Sat, Jun 11, 2011 at 2:16 PM, Daniel Friesen
> wrote:
>
>> There's also the technique Raphael JS uses.
>>
> I'm quite fond of Raphael for interactive graphics -- it provides a nice
> little JS API that maps things to native elements in either SVG or VML (for
> older versions of IE which lack SVG). The downside for more static things is
> that you won't necessarily get your graphics included in search engines or
> other spidered destinations, and it's probably harder to adapt them to other
> kinds of data export. (For instance to do a PDF export you'd either need to
> be able to execute the JavaScript to produce SVG, then capture the SVG, or
> add a second renderer in your export tool that produces suitable output.)
>
> Of course if you're only ever going to use it in-browser for private sites,
> no worries. :D

Yes, I'm not very worried about search engines and probably most of the 
user won't worry about that too. I might render some fall-back table 
with tasks for the sake of it, though.

Raphael JS seems a nice thing to get started, so I'll probably use it 
and create some kind of an SVG overlay and maybe move to pure HTML at 
some later point.

Thanks,
Nux.

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

Re: [Wikitech-l] SVG image display bug (width-dependent)

[Maciej Jaros]

Neil Kandalgaonkar (2011-07-14 01:40):
> That's interesting. Your SVG file seems to be hand-edited, using xlink
> and entities so the repetitive elements, like the court, are only
> defined once. It's clever.

Using xlink alone shouldn't be a problem. You can see this works fine 
from quite some time here (all balls are defined and then used):
http://commons.wikimedia.org/wiki/File:Snooker_table_drawing.svg

> http://commons.wikimedia.org/wiki/File:Badminton_court_legal_bounds.svg
>
> When rendering this at any width of 160px or above, the renderer renders
> it correctly, e.g.:
>
>   http://goo.gl/Onhww  (160px thumbnail, upload.wikimedia.org)
>
> However, for sizes below 160px, most of the picture is missing in the
> rendering:
>
>   http://goo.gl/U6RPs  (159px thumbnail)
>
> Can this be fixed?

Have you tried moving some stuff from defs to an actual image? You could 
at least move  outside (below) defs.

You could also try removing all text tags and see if it works. Some SVG 
renderers act funny when you scale fonts - if you set font to a very 
small size renders might ignore it and make characters ridiculously 
large or make them disappear. In this situation if you multiply (by hand 
or script) all text elements sizes and then scale them down with a 
transformation then everything will be fine. It's a total mystery to me. 
Fonts just seems to be badly implemented in most renderers (or was 
haven't tested this for a while).

Also I've just noticed that you've set  width and height to "100%". 
Maybe setting this to some static numbers would help. It seems to 
prevent e.g. Opera to scale the image with CTRL +/-.

Regards,
Nux.

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

Re: [Wikitech-l] Experimental Wikia RTE branch for MediaWiki trunk

[Maciej Jaros]

Dmitriy Sintsov (2011-07-21 09:48):
> Brion Vibber  [Fri, 6 May 2011 16:34:20 -0700]:
>
>> This gets a little scarier-looking once it turns out that the core 
>> Parser class has a hojillion little patches on it that the extension 
>> depends on, which do much of the annotation & placeholder insertion. 
>> I should be able to refactor most of those into either hooks or more 
>> cleanly-factored Parser methods that can be subclassed more directly 
>> in RTEParser; that'll make the extension's integration job a lot 
>> easier on a stock 1.18. Whee! Well one thing's for sure -- I'm going 
>> to have spent a lot more time looking at the guts of the current 
>> parser before this is done. ;) It's also definitely reminding me why 
>> I don't like our current parser code. ;) But a lot of it can be made 
>> cleaner and more extensible I think without any behavior changes, 
>> which gets us a long way in the short term.
>>
> I've cloned it from
> git://gitorious.org/mediawiki-wikia-rte/mediawiki-wikia-rte.git and I am
> having huge troubles even getting it to run without fatal errors in
> 1.17. It seems to require Wikia custom classes and extensions
> (WikiaSuperFactory, SASS, ThemeSettings- and more?) and also it accesses
> properties of Oasis skin (while I have my own Vector-derived skin with
> different name). I wonder should I spend some more days with it, or it's
> not going anywhere. I am having troubles finding stable and wide-browser
> supporting WYSIWYG editor for 1.17. FCKeditor worked with 1.15
> (imperfect, but worked) but I already made quite enough of commits into
> my customer's 1.17 installation so I don't want to delete everything and
> start with 1.15 / 1.16 from scratch.. *sigh*

I'm almost sure we have plain 1.16 at work (not sure cause I'm on 
vacation) with FCKeditor extension. You just need to disable the new 
editor for it to work, but Vector skin works fine with it. I remember 
I've made some changes to the extensions CSS and made a bit of 
i18n/l10n, but don't remember of them being specific to 1.16 or in any 
way crucial. So I'm guessing you should be able to port everything back 
to 1.16. Just remember to get rid of mw.config thingies form JavaScript 
if you've used them already. You will also probably need to turn on 
jQuery as it was not available on all pages by default in 1.16.

Regards,
Nux.

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

Re: [Wikitech-l] RFC: Modifying diff colors due to color blindness issues

[Maciej Jaros]

Leo Koppelkamm (2011-07-27 23:31):
> On Wednesday, July 27, 2011 at 8:33 PM, George Herbert wrote:
>> Could we get visual mockups of the various proposals, preferably
>> stacked on one page so we can compare them fairly easily?
> Red/Green
> http://commons.wikimedia.org/?debug=true&diff=55008419&withCSS=MediaWiki:Gadget-diffRedGreen3.css
>
> Red/Blue
> http://commons.wikimedia.org/?debug=true&diff=55008419&withCSS=MediaWiki:Gadget-diffRedGreen4.css
>
> Optionally without the small grey border:
>
> Red/Green w/o border
> http://commons.wikimedia.org/?debug=true&diff=55008419&withCSS=MediaWiki:Gadget-diffRedGreen2.css
>
> Red/Blue w/o border
> http://commons.wikimedia.org/?debug=true&diff=55008419&withCSS=MediaWiki:Gadget-diffRedGreen5.css
>

I like the first red green (without the border), but if at it there 
should probably be more distinction between the grey, red and green 
colours. I was working on a picture on Commons some time ago after being 
poked by a colour blind person and found out that the problem was not 
the colour itself, but Value of colours (Value as in HSV model). So what 
I did is changed one colour a bit and made a greyscale image of the 
picture and I've then changed a bit more until I was able to 
differentiate the colours in greyscale mode.

So in this case I would at least change the colours so that unchanged 
line (grey) would be different (in Value) from the changed line (red/green).

Regards,
Nux.

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

Re: [Wikitech-l] Does MediaWiki has an extension which provides function for readers to take reading notes?

[Maciej Jaros]

Philip Tzou (2011-07-22 06:12):
> Hi, everyone:
>
> I wanna find a MW extension which can provide reading-notes-taken
> function for wiki readers. Do we have one?
>

Not sure if this will help you as I haven't seen an extensions like this 
for MW itself but there are various note extensions for browsers. I've 
seen many kinds of note taking extensions for FF and Opera has the 
ability to take notes from pages built in.

Regards,
Nux.

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

Re: [Wikitech-l] Experimental Wikia RTE branch for MediaWiki trunk

[Maciej Jaros]

Dmitriy Sintsov (2011-07-29 07:54):
> Speaking of server-side (php interface), yes, MediaWiki is largely
> backwards compatible (except for static call Linker::link() and few
> ancient things, like wfLoadExtensionMessages‎() and so on). Speaking of
> client-side (Javascript), it is not so simple. Since 1.17, I am
> experiencing weirdness with client-side scripts in non-ResourceLoader
> ready extensions. For example my own Extension:QPoll had minor glitches
> until I've ported it to ResourceLoader. I guess that is because the
> scripts are now loaded at bottom, not at the top, or maybe due to jQuery
> introducing it's own scopes, while old scripts were assuming to have run
> in window scope. However, QPoll has very little tiny client-side script,
> while Extension:CategoryBrowser also have glitches and scripts are much
> larger - I still don't have the time to port it.
I think you shouldn't use mw.whatever stuff just yet (so the code will 
be backward compatible). Most of the stuff was already available just 
phrased differently. I think you should use jQuery anyway where you can 
instead of wikibits functions, though (e.g. $() instead of addOnloadHook()).

As for bottom/top this should probably a problem only for move from 1.16 
to 1.17 rather then the other way around. So if you managed to make it 
work for 1.17 it should work for 1.16.

> In contrary to claims
> that Extension:FCKeditor works fine in 1.17, I've experienced opposite
> with my own Vector-based skin, not Monobook skin. Of course, I might try
> again, however I really disliked the way the extension is coded - with
> assumption that Monobook skin is being used, unreliable tricks with
> Parser and so on.

 From what I've seen the problem is not a Vector skin itself but the new 
wikieditor (editor toolbar). If you will disable it it should be fine.

Regards,
Nux.


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

Re: [Wikitech-l] We need to make it easy to fork and leave

[Maciej Jaros]

John Elliot (2011-08-12 13:36):
> [...]
> The thing about me, is that there can be hundreds of thousands of people
> like me, and when you add up all our contributions, you have a
> formidable force. I can't host Wikipedia, but there could be facilities
> in place for me to be able to easily mirror the parts of it that are
> relevant to me. For instance, on my Network administration page, I have
> a number of links to other sites, several of which are links to Wikipedia:
>
>http://www.progclub.org/wiki/Network_administration#Links
>
> Links such as:
>
>http://en.wikipedia.org/wiki/Subversion
>
> Now by rights there could be a registry in my MediaWiki installation
> that recorded en.wikipedia.org as being another wiki with a particular
> content distribution policy, such as a policy permitting local
> mirroring. MediaWiki, when it noticed that I had linked to such a
> facility, could replace the link, changing it to a link on my local
> system, e.g.
>
>http://www.progclub.org/wiki/Wikepedia:Subversion
>
> ...
>
>

That's a very interesting idea... And it should be really hard to do.

Let's say you linked the Subversion article and you've set up that the 
address:
http://en.wikipedia.org/wiki/$1
To be hosted as:
http://www.progclub.org/wiki/en-wiki:...

Now each time your user clicks on a link everything gets registered in 
your installation as "to be downloaded" and upon given number of clicks 
and/or given number of resources and/or at given time to be downloaded 
to your site.

The tricky part would be that you not only need the article itself, but 
also it's templates and that can be quite a lot with first articles you 
get. Further more this extension would probably need to allow users to 
opt-out of downloading images and maybe instead of getting wikicode just 
host rendered HTML so that you don't really need to host templates.

And speaking of images - the problem with any of the solutions is - who 
would really want to spend money to host all this data? There were times 
when Wikipedia had many hold ups, but now I feel there are more chances 
that your own server would choke on the data rather then Wikipedia 
servers. Maybe ads added to self hosted articles would be worth it, but 
I kinda doubt anyone would want to host images unless they had to.

BTW. I think a dynamic fork was already made by France Telecom. They 
fork Polish Wikipedia and update articles in a matter of minutes (or at 
least they did last time I've checked - they even hosted talk pages so 
it was easy to test). You can see the fork here:
http://wikipedia.wp.pl/

Note that they don't host images though they host image pages.

Regards,
Nux.

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

Re: [Wikitech-l] RFC: Geo RSS for recent changes

[Maciej Jaros]

Strainu (2011-08-20 23:53):
> Hi,
>
> Just a quick thought about the recent change feed [1]. Wouldn't it be
> interesting to transform it in a GeoRSS [2]?
>
> This would be done by adding the coordinate from the articles, if
> available, and/or by using rssToGeo [3] where coordinates are
> unavailable? I'm not necessarily looking to get that included in
> MediaWiki, but I would like to see if creating a "recent changes on a
> map" service would be useful to someone.

I think this might be useful if one would be able to choose some region 
on a map and create and RSS for this region only (something like 
"changes in my neighbourhood").

Cheers,
Nux.

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

Re: [Wikitech-l] Asking for notes on a MediaWiki:Sidebar replacement

[Maciej Jaros]

jida...@jidanni.org (2011-08-23 01:56):
> "DF" == Daniel Friesen  writes:
> DF>  For something like this where users are going to want to be able to drag
> DF>  and reorganize things do we have to do this in a slow way that works
> DF>  without JS?
>
> Yes you do. You need to offer an alternate way for one to configure
> their many wikis via batch configuration files, as they are not going to
> do each one by hand in some browser.

You could probably add JSON input. This could be achived by adding a 
textarea input to which one could simply copy&paste some data and which 
would normally be changed with JS. So when JS would be available you 
could simply hide the input.

> I'd like to see any comments or requirements people have of an
> interface/system for editing the sidebar.

  * Show in which languages each menu item is available and allow one to
quickly add more language versions.
  * Show current user language by default and allow to view other
version (e.g. in tooltip).
  * Move items or branches (whole submenu) up or down and between branches.
  * Allow users to compose their own menu and save it in their preferences.
  * Allow adding JS calls to each item (preferably with a fallback page
- when JS is not available).
  * Ability to change position of special menus (e.g. languages and
toolbox).
  * Each submenu should have "defaults to visible" true/false attribute
(e.g. languages are visible by default when no cookie is set).
  * Each menu item should have a changeable id attribute e.g. "p-lang"
for language menu. This should probably only be available in some
advanced mode (as changing id would break some existing scripts).
  * Ability to add/change access keys for items (also probably in
advanced mode).


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