Re: [Wikitech-l] Removing test suites from trunk
* Victor Vasiliev [Tue, 7 Dec 2010 22:12:58 +0300]: > On Tue, Dec 7, 2010 at 10:07 PM, Brion Vibber wrote: > > Offhand suggestion: can we pack/compress the language files in a way > that > > keeps them smaller on the server but leaves them usable? > > > > -- brion > > I thought about that yesterday. Even if we compress them, they are 11 > MB in gzip and 6.5 MB in LZMA as far as I remember. > > And it will not decrease the distribution size for apparent reason. > It will decrease the size of installation, at least. And there are probably more of installations than distributives. Dmitriy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making usability part of the development process
* Ashar Voultoiz [Tue, 07 Dec 2010 19:19:53 +0100]: > On 06/12/10 16:57, Trevor Parscal wrote: > > I personally think XSL is awesome, and would defend it with > > vigor. > > I love XSL too. Probably the easiest way to render an XML data file. > It's easy only when XSL style sheet already exists. Even simple loops were not so easy to peform in that language, at least in old v1.0 I've used some years ago. And expressions enclosed in tags are bloated. XQuery has easy loops and much less bloat, however it's much less supported in PHP. > Another approach could be inspired by ruby on rails way. You define a > general application layout using HTML with special directives such as: > > > ><%= yield %> > > > "yield" is where the current view should be inserted. This mean a > graphist / skinner, just have to know about HTML/CSS :-b > > > To create your view, you use rhtml (ruby html) which is plain HTML in > which you can insert ruby code using <% %> or <%= %> : > > > <% @articles.each do |article| %> > > <%= article.title %> > <%= link_to 'Show', article > <%= link_to 'Edit', edit_path( article ) > > > > It does make thing easier, since the whole backend is hidden. Its role > is just to provide the correct variables (in the above case 'article' > which is an array of articles objects). > Not bad. BTW, a good skin templating probably could also become an alternative wiki templating for wiki articles. Dmitriy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Plea to get [Bug 21526 - Bug in Djvu text layer extraction] implemented
On 08/12/10 11:58, Billinghurst wrote: > Can I again ask that the powers that be please assist to roll-out a > bug fix that the Wikisource sites do need for a usability fix >https://bugzilla.wikimedia.org/show_bug.cgi?id=21526 Done. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Plea to get [Bug 21526 - Bug in Djvu text layer extraction] implemented
Billinghurst wrote: > If it is the noisy squeaky and disruptive that is the means to get > something implemented, we can go there, however, surely, surely, > surely, what we want is the polite and considerate. This is for Wikisource? You could always threaten to start uploading WikiLeaks cables. :-) In all seriousness though, your best bet is usually to bother people on IRC for specific fixes like this. Yes, bother. Your second best bet is mailing list posts like this, though the diffusion of responsibility aspect makes utilizing mailing lists more difficult. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Plea to get [Bug 21526 - Bug in Djvu text layer extraction] implemented
Can I again ask that the powers that be please assist to roll-out a bug fix that the Wikisource sites do need for a usability fix https://bugzilla.wikimedia.org/show_bug.cgi?id=21526 The bug was reported over a year ago, Reported:2009-11-15 21:21 UTC by Simon Lipp and fixed five months ago ThomasV 2010-07-07 11:07:00 UTC Thanks for patch and the detailed explanation. I commited it (r69139) Implementation to servers? Unknown Requests for implementation? Ignored Any issues with means of implementation? Not known, not visible Systematic route to implementation? Seemingly not followed, and forgotten It is so incredibly frustrating to have to get continually ask for the simple fix to be put in place for a whole set of sister sites. It is so incredibly humiliating to almost to get down and beg that some consideration be given to some of the smaller sites. The utter silence that pervades these matters has moved from disregard and moving into disgraceful. That there is no communication or ability to even get an understanding of what can be expected is now well past disappointing and into unprofessional. I understand that there is a big picture to consider, however, there is the matter of consideration, courtesy and respect, and these very sadly seem to be missing. The situation seems to be going from neglect and moving towards something approaching culpability by the management system. If it is the noisy squeaky and disruptive that is the means to get something implemented, we can go there, however, surely, surely, surely, what we want is the polite and considerate. billinghurst This message was sent using iSage/AuNix webmail http://www.isage.net.au/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Removing test suites from trunk
Brion Vibber wrote: > Offhand suggestion: can we pack/compress the language files in a way that > keeps them smaller on the server but leaves them usable? > > -- brion We can provide them gzipped and require them with compress.zlib:// prepended to the filename. That will work magically™ as far as the zlib extension is enabled (which almost always will be the case). We can perform the same magic with bzip2 but it may be a less frequent extension. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making usability part of the development process
Daniel Friesen wrote:
> On 10-12-07 08:18 AM, Bryan Tong Minh wrote:
>> I was first like wtf as well, but on the other hand this way skin
>> building would be much more accesibles for non-programmer mediawiki
>> users. Regular wiki users do know wikitext, as opposed to PHP. I'm not
>> entirely sure though that this would be good for your sanity. I
>> wouldn't discard the idea immediately, insane as it may seem.
>>
> ^_^ I was drafting a response Platonides' comment, ie: an example of a
> chunk of MonoBook code using a WikiText style template language... in
> order to demonstrate the insanity of using the style that our
> preprocessor preprocesses as a template language for skins...
> I decided it sounded obviously insane enough that I didn't need to...
> ;) wan't me to re-start that example...?
>
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
I'm not sure myself of the sanity of such approach. :)
But if {$title|escape:html} is considered "friendly", it'd be much
better to use a known syntax than creating a new one.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] 1.17 branched
2010/12/7 Roan Kattouw : > I'd also like to call upon everyone to help out with code review. Another addendum inspired by IRC chatter: not just MediaWiki core needs to be reviewed, extensions deployed on WMF wikis need review too. So if you happen to be familiar with the code of one of those, your help is appreciated as well. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] 1.17 branched
On Wed, Dec 8, 2010 at 7:52 AM, Roan Kattouw wrote: > It's been pointed out on IRC that you need to be in the coder group on > mediawiki.org to be able to do this. If you're not in that group but > are a committer or otherwise well-known and in good standing, just ask > for it. Anyone who's already a coder can promote others (it's viral!). > > Roan Kattouw (Catrope) And if you can't find anyone to do it on IRC (which will/should be rare), just drop a note at Project:Requests on mediawiki.org requesting it and someone will do it. -Peachey ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] 1.17 branched
2010/12/7 Roan Kattouw : > When you commit or find a revision post-r77974 that you feel should be > in 1.17 (bugfixes, typically, no new features), tag it with "1.17" in > CodeReview. It's been pointed out on IRC that you need to be in the coder group on mediawiki.org to be able to do this. If you're not in that group but are a committer or otherwise well-known and in good standing, just ask for it. Anyone who's already a coder can promote others (it's viral!). Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] 1.17 branched
You probably noticed, or heard in advance that it would happen, but I figured I'd announce it anyway: 1.17 was branched today. The branch is in /branches/REL1_17 and the branch point is r77974. When you commit or find a revision post-r77974 that you feel should be in 1.17 (bugfixes, typically, no new features), tag it with "1.17" in CodeReview. Please do this even if you're not afraid of SVN merging, so we can merge stuff in batches and keep the commit noise down. Nothing has been merged yet, although a few things seem to have been tagged already. When you find something pre-r77974 that you think should be backed out of 1.17 (i.e. reverted in the branch), tag it with "revert1.17". This shouldn't happen very often, so feel free to do this yourself if you know how. The only thing that's been backed out so far is a refactoring of the skin system in r77893. After merging/reverting, the tag should be removed. I'd also like to call upon everyone to help out with code review. Of course not everyone feels comfortable reviewing everything, but by all means review what you feel comfortable reviewing. Even if you're not an experienced reviewer/developer and only review trivial changes or changes to one specific component you're familiar with, you're taking work out of the hands of other reviewers. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Our skin system, and a skin's class name
I ran into an issue while experimenting with something today.
I created a voidbook skin with a SkinVoidBook class which was going to
be a test skin to duplicate monobook in a compiled template language.
But I did it using the extension technique of setting $wgValidSkinNames
and $wgAutoloadClasses like any other 3rd party skin.
I ran into an issue with the skin not being loaded.
After I debugged it I found out that for several years our skin system
has been doing something utterly screwed up...
Here's how Skin::newFromKey works with monobook.
With $key = "monobook" passed to it the method Skin::getSkinNames() to
get the fully filled $wgValidSkinNames data.
$skinName becomes "MonoBook" and $className becomes "SkinMonobook"
`$className = 'Skin' . ucfirst( $key );`
The method does a class_exists triggering the autoloader checking for a
"SkinMonobook" class.
SkinMonobook is not found so the method loads up skins/MonoBook.php
after optionally loading skins/MonoBook.deps.php, this loads the
SkinMonoBook class.
class_exists returns true, and so `new $className` is called... This
creates an instance of SkinMonoBook from the $className SkinMonobook.
See the screw up there? For a long time we've been sticking to naming
our skin classes by the SkinMonoBook convention... while really, the
skin system has been trying to load SkinMonobook and only succeeding
because we use require_once directly loading SkinMonoBook and php's
class system happens to be case insensitive so when we ask for
SkinMonobook it gives us SkinMonoBook.
Problem! Our autoloader is NOT case insensitive.
So anyone following our internal conventions while trying to create a
skin inside of an extension and they happen to decide on a skin name
using a capital letter in the middle of the word gets a nasty suprise.
Instead of the way it played out with MonoBook, VoidBook gets this result.
$key = "voidbook"; Skin::newFromKey sets $skinName = "VoidBook";
$className = "SkinVoidbook";
class_name calls our autoloader asking for "SkinVoidbook", the class is
actually SkinVoidBook so our autoloader does NOT load the class. The
class_exists returns false, Skin::newFromKey continues along, doesn't
see skins/SkinVoidBook.deps.php so it skips it... then it tires to
require skins/SkinVoidBook.php, now because this is an extension based
skin it trips up and we get a cryptic fatal php error.
Now we've defined $wgValidSkinNames as an array mapping skin ids to
names of those skins... however from what I see convention violates this
notion. "cologne" is "CologneBlue" yet the skin's actual name is
"Cologne Blue". "standard" is "Standard" yet the skin's actual name is
"Classic".
Despite the array being documented as a list of skin names, it really
appears to conform to something that maps lower case skin ids to their
proper cased counterparts which when prefixed with "Skin" will give you
a skin's class name. While we use the i18n system for the real skin "name".
This is actually fairly well supported by the fact that we use that skin
"name" when we require a skin file from the skins folder.
So to fix this bug I propose we change the documented format of
$wgValidSkinNames to be an array mapping skin ids "monobook" to the
proper cased key used for building class names and requiring files. And
change `$className = 'Skin' . ucfirst( $key );` to `$className =
"Skin{$skinName}";` so that "monobook" will try to load SkinMonoBook
instead of SkinMonobook.
As a side effect of this, it will also theoretically become possible to
alias skins by doing something like `$wgValidSkinNames = "MonoBook";`
which considering there are already cases in the wild where people have
duplicated monobook to have varying styles like ReferenceBook,
WhiteBook, etc... would probably be a desirable feature.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Looking for a mediawiki.org dump
2010/12/6, wikitech-l-requ...@lists.wikimedia.org : > Date: Mon, 6 Dec 2010 18:50:45 +1100 > From: Andrew Dunbar > > Could anybody help me locate a dump of mediawiki.org while the dump > server is broken please? I only need current revisions. Use your Google-fu; there are some dumps available at various locations on the internet (archive.org, Pirate Bay). What is perhaps more important: can the checksums be made available somewhere while the dump server is down? That way, we can verify the dumps we must now fetch from untrusted sources. I hope the dump server goes back online soon, I need the SQL dumps for research into link mining... Regards, Lars Buitinck ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Removing test suites from trunk
On Tue, Dec 7, 2010 at 10:07 PM, Brion Vibber wrote: > Offhand suggestion: can we pack/compress the language files in a way that > keeps them smaller on the server but leaves them usable? > > -- brion I thought about that yesterday. Even if we compress them, they are 11 MB in gzip and 6.5 MB in LZMA as far as I remember. And it will not decrease the distribution size for apparent reason. --vvv ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making usability part of the development process
On 10-12-07 10:19 AM, Ashar Voultoiz wrote: > On 06/12/10 16:57, Trevor Parscal wrote: > >> I personally think XSL is awesome, and would defend it with >> vigor. >> > I love XSL too. Probably the easiest way to render an XML data file. > > Another approach could be inspired by ruby on rails way. You define a > general application layout using HTML with special directives such as: > > > > <%= yield %> > > > "yield" is where the current view should be inserted. This mean a > graphist / skinner, just have to know about HTML/CSS :-b > > > To create your view, you use rhtml (ruby html) which is plain HTML in > which you can insert ruby code using<% %> or<%= %> : > > > <% @articles.each do |article| %> > > <%= article.title %> > <%= link_to 'Show', article > <%= link_to 'Edit', edit_path( article ) > > > > It does make thing easier, since the whole backend is hidden. Its role > is just to provide the correct variables (in the above case 'article' > which is an array of articles objects). > > > I think Symfony, now a day a popular PHP framework, use this system as well. > > > [1] http://www.symfony-project.org/ > > > erb/rhtml/erubis/etc... is basically nearly the same thing as the blocks we already use. Also, one of my goals is to provide templates which are php-less so that even environments like wiki farms can provide the ability for skins to be customized without worrying about php injection. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Removing test suites from trunk
Offhand suggestion: can we pack/compress the language files in a way that keeps them smaller on the server but leaves them usable? -- brion On Dec 7, 2010 10:42 AM, "Aryeh Gregor" > wrote: > On Mon, Dec 6, 2010 at 6:46 AM, Huib Laurens wrote: >> But a other option is to add a second download option where people can >> download mediawiki with only EN and make tarballs for all languages >> available so people can add the languages they want. Maybe something that >> can be done on a mirror site. > > I don't think this is a good idea. People will opt for the smaller > download if given a choice, and then their users won't be able to > switch their interface language. > > ___ > 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] Removing test suites from trunk
On 7 December 2010 20:08, Petr Kadlec wrote: > Well, the hint to use sparse checkouts applies this way, too… You can > omit the testing directories from your checkout, and even subsequent > SVN updates will skip them. After checkout, just call > svn up --set-depth exclude maintenance/tests > and you should be set. svn up --set-depth exclude maintenance/tests svn: 'exclude' is not a valid depth; try 'empty', 'files', 'immediates', or 'infinity' There is no mention of 'exclude' even in the docs of development version of svn. -Niklas -- Niklas Laxström ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Removing test suites from trunk
On Mon, Dec 6, 2010 at 6:46 AM, Huib Laurens wrote: > But a other option is to add a second download option where people can > download mediawiki with only EN and make tarballs for all languages > available so people can add the languages they want. Maybe something that > can be done on a mirror site. I don't think this is a good idea. People will opt for the smaller download if given a choice, and then their users won't be able to switch their interface language. ___ 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
2010/12/7 Trevor Parscal : > I have made this point before, clearly upon deaf ears - but I will make > it again. > I don't think this'll surprise anyone, but I'll just state that I fully agree with Trevor here. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making usability part of the development process
On Tue, Dec 7, 2010 at 9:46 AM, Paul Houle wrote: > I18N is essential if you need to cover multiple linguistic zones. > If you don't, I18N can increase the cost of making simple changes by a > factor of 3 to 5. Not for us, in my experience. The developers just write the stuff purely in English and then volunteers handle localization. The cost might technically be much higher, but it's mostly handled by volunteers, so it doesn't actually hurt much of anything. The only difference for developers is we have to put messages in their own file and refer to them with message functions, but it's not a noticeable cost once you get used to it. Also I guess we have to spend some time designing and optimizing the localization system, but that's only a small part of development, not a really big cost. In any event, MediaWiki being localizable is entirely non-negotiable at this point, so if there's a cost, we're going to pay it anyway. What sort of cost are you talking about here, though? I can't think what sort of i18n system would require simple UI changes to take three to five times the work. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making usability part of the development process
On 06/12/10 16:57, Trevor Parscal wrote: > I personally think XSL is awesome, and would defend it with > vigor. I love XSL too. Probably the easiest way to render an XML data file. Another approach could be inspired by ruby on rails way. You define a general application layout using HTML with special directives such as: <%= yield %> "yield" is where the current view should be inserted. This mean a graphist / skinner, just have to know about HTML/CSS :-b To create your view, you use rhtml (ruby html) which is plain HTML in which you can insert ruby code using <% %> or <%= %> : <% @articles.each do |article| %> <%= article.title %> <%= link_to 'Show', article <%= link_to 'Edit', edit_path( article ) It does make thing easier, since the whole backend is hidden. Its role is just to provide the correct variables (in the above case 'article' which is an array of articles objects). I think Symfony, now a day a popular PHP framework, use this system as well. [1] http://www.symfony-project.org/ -- Ashar Voultoiz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Removing test suites from trunk
On 7 December 2010 14:59, wrote: > Me too. Please move all the expert testing stuff to a different place > where the experts can use an expert command to fetch it, and stop > bloating we regular WikiSysops SVN updates. Thanks. Well, the hint to use sparse checkouts applies this way, too… You can omit the testing directories from your checkout, and even subsequent SVN updates will skip them. After checkout, just call svn up --set-depth exclude maintenance/tests and you should be set. -- [[cs:User:Mormegil | Petr Kadlec]] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Removing test suites from trunk
On 07/12/10 18:51, Chad wrote: > If we do go that route, we should additionally package > the tests for those that would like to download them. Sounds good to me :-b -- Ashar Voultoiz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Removing test suites from trunk
On Tue, Dec 7, 2010 at 12:44 PM, Ashar Voultoiz wrote: > On 07/12/10 04:11, Chad wrote: >> I think the easiest solution is to just tweak the make-release >> script to exclude the tests directory (wherever we end up >> putting it). > > It might be handy to get the test suites deployed on as many hosts as > possible. This would let users run the test right out of the box and > might help us fixing bugs later. > I'm not set one way or the other on including them in the default download archive. If we do, that's ^^^ the way to do it though. If we do go that route, we should additionally package the tests for those that would like to download them. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Removing test suites from trunk
On 07/12/10 14:59, jida...@jidanni.org wrote: > M> SVN is convenient for installations and upgrades. That's certainly > M> why I use it. > Me too. Please move all the expert testing stuff to a different place > where the experts can use an expert command to fetch it, and stop > bloating we regular WikiSysops SVN updates. Thanks. svn is already considered "expert stuff" ;-) -- Ashar Voultoiz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Removing test suites from trunk
On 07/12/10 04:11, Chad wrote: > I think the easiest solution is to just tweak the make-release > script to exclude the tests directory (wherever we end up > putting it). It might be handy to get the test suites deployed on as many hosts as possible. This would let users run the test right out of the box and might help us fixing bugs later. Just my 2 cents. -- Ashar Voultoiz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making usability part of the development process
On 10-12-07 08:18 AM, Bryan Tong Minh wrote:
> On Tue, Dec 7, 2010 at 5:12 PM, Trevor Parscal wrote:
>
>> Oh please no!
>>
>> - Trevor
>>
>> On 12/7/10 7:26 AM, Platonides wrote:
>>
>>> Daniel Friesen wrote:
>>>
PHP ->XSL doesn't quite feel like much of an improvement in terms of
cutting down on the verbose redundant code boilerplate required to
insert something.
ie:doesn't look much better than>>> $this->text("title") ?>, as opposed to {$title|escape:html}.
>>> This seems an argument for using the preprocessor for the skin system,
>>> in order to include the variables into the raw html.
>>>
>>>
> I was first like wtf as well, but on the other hand this way skin
> building would be much more accesibles for non-programmer mediawiki
> users. Regular wiki users do know wikitext, as opposed to PHP. I'm not
> entirely sure though that this would be good for your sanity. I
> wouldn't discard the idea immediately, insane as it may seem.
>
^_^ I was drafting a response Platonides' comment, ie: an example of a
chunk of MonoBook code using a WikiText style template language... in
order to demonstrate the insanity of using the style that our
preprocessor preprocesses as a template language for skins...
I decided it sounded obviously insane enough that I didn't need to...
;) wan't me to re-start that example...?
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making usability part of the development process
On Tue, Dec 7, 2010 at 5:12 PM, Trevor Parscal wrote:
> Oh please no!
>
> - Trevor
>
> On 12/7/10 7:26 AM, Platonides wrote:
>> Daniel Friesen wrote:
>>> PHP -> XSL doesn't quite feel like much of an improvement in terms of
>>> cutting down on the verbose redundant code boilerplate required to
>>> insert something.
>>> ie: doesn't look much better than>> $this->text("title") ?>, as opposed to {$title|escape:html}.
>> This seems an argument for using the preprocessor for the skin system,
>> in order to include the variables into the raw html.
>>
I was first like wtf as well, but on the other hand this way skin
building would be much more accesibles for non-programmer mediawiki
users. Regular wiki users do know wikitext, as opposed to PHP. I'm not
entirely sure though that this would be good for your sanity. I
wouldn't discard the idea immediately, insane as it may seem.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making usability part of the development process
Oh please no!
- Trevor
On 12/7/10 7:26 AM, Platonides wrote:
> Daniel Friesen wrote:
>> PHP -> XSL doesn't quite feel like much of an improvement in terms of
>> cutting down on the verbose redundant code boilerplate required to
>> insert something.
>> ie: doesn't look much better than> $this->text("title") ?>, as opposed to {$title|escape:html}.
> This seems an argument for using the preprocessor for the skin system,
> in order to include the variables into the raw html.
>
>
> ___
> 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] Fwd: Re: [Mediawiki-l] vector components many blank lines
These blank lines should not - under any circumstances - be here. But I do know why they are... Tim Starling modified the standard distribution of JSMin[1] in some good and some bad ways. These blank lines are the result of one of these modifications which I find to be misguided. He's basically only compressed horizontal white-space, leaving new line characters in place. The blank lines you see are where the comments used to be. I have made this point before, clearly upon deaf ears - but I will make it again. * ResourceLoader has 2 modes. Production and Development (or debug) mode. * Production mode should be as fast as possible for users, period. * Development mode should be as easy as possible for developers, period. * Any attempt to blend the two only serves to diminish the effectiveness of either mode. If you want a version of the script that has not been compressed add debug=true to the URL or set $wgResourceLoaderDebug = true; in your LocalSettings.php. 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. - Trevor [1] http://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki/author/tstarling&path=/trunk/phase3/includes/libs/JSMin.php On 12/7/10 5:32 AM, jida...@jidanni.org wrote: > Why so many blank lines in this vector component? > $ cat yy > set > 'http://transgender-taiwan.org/load.php?debug=false&lang=zh-tw&modules=startup&only=scripts&skin=vector' > GET $1|perl -nwe 'print " $." if /^$/' > $ sh yy # These lines are blank: >1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 20 26 27 28 29 32 33 34 37 > > > http://transgender-taiwan.org/load.php?debug=false&lang=zh-tw&modules=site&only=scripts&skin=vector&version=19700101T00Z > is affected too. > > Yes these aren't meant for human consumption. > > ___ > MediaWiki-l mailing list > mediawik...@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mediawiki-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making usability part of the development process
Bryan Tong Minh wrote:
> On Tue, Dec 7, 2010 at 4:26 PM, Platonides wrote:
>> Daniel Friesen wrote:
>>> PHP -> XSL doesn't quite feel like much of an improvement in terms of
>>> cutting down on the verbose redundant code boilerplate required to
>>> insert something.
>>> ie: doesn't look much better than >> $this->text("title") ?>, as opposed to {$title|escape:html}.
>>
>> This seems an argument for using the preprocessor for the skin system,
>> in order to include the variables into the raw html.
>>
> Skin sytem in wikitext?
Only the preprocessing.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making usability part of the development process
On Tue, Dec 7, 2010 at 4:26 PM, Platonides wrote:
> Daniel Friesen wrote:
>> PHP -> XSL doesn't quite feel like much of an improvement in terms of
>> cutting down on the verbose redundant code boilerplate required to
>> insert something.
>> ie: doesn't look much better than > $this->text("title") ?>, as opposed to {$title|escape:html}.
>
> This seems an argument for using the preprocessor for the skin system,
> in order to include the variables into the raw html.
>
Skin sytem in wikitext?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making usability part of the development process
Daniel Friesen wrote:
> PHP -> XSL doesn't quite feel like much of an improvement in terms of
> cutting down on the verbose redundant code boilerplate required to
> insert something.
> ie: doesn't look much better than $this->text("title") ?>, as opposed to {$title|escape:html}.
This seems an argument for using the preprocessor for the skin system,
in order to include the variables into the raw html.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making usability part of the development process
On 12/7/2010 2:23 AM, Daniel Friesen wrote: > One thing our skin system "does" have is an extensive linker and system > for building tooltips and accesskeys for things using our i18n system. > And calls to the message system from skins are all over the place: > tagline, jumpto, and basically every header that's part of a skin itself > is all generated by calls to the i18n system, they are not hardcoded in > SkinTemplate. And that's the rub. I18N is essential if you need to cover multiple linguistic zones. If you don't, I18N can increase the cost of making simple changes by a factor of 3 to 5. I was working on a product aimed at the Brazillian market (pt-br) years ago, and the first iteration of the product was I18N'ed to the sky because we wanted to get investment from the en, es and pt-br zones. Well, that investment didn't come, we bootstrapped, and the first version to really hit the web was built exclusively for the pt-br zone. Instead of requiring a committee to meet and wasting hours just to move a button from one place to another, we could just do it. If your resources aren't infinite, I18N can have a definitely harmful effect on UI quality because it tries to break your hands every time you want to make a tweak. As for XSLT, it's one of those languages that can't decide if it wants to be Turing complete or not. XSLT, as an output templating language, is the kind of thing that takes a task an intern can do in five minutes and makes it a job that you have to bring a consultant in for three weeks. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Removing test suites from trunk
On Tue, Dec 7, 2010 at 9:02 AM, Chad wrote: > The consensus is that they're not moving it out of /trunk/phase3. > s/they/we/ (not sure why I left myself out of this...) -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Removing test suites from trunk
On Tue, Dec 7, 2010 at 8:59 AM, wrote: > I'm the first to add a vote to > https://bugzilla.wikimedia.org/show_bug.cgi?id=26259 ! Hope it gets > counted. > M> SVN is convenient for installations and upgrades. That's certainly > M> why I use it. > Me too. Please move all the expert testing stuff to a different place > where the experts can use an expert command to fetch it, and stop > bloating we regular WikiSysops SVN updates. Thanks. > The consensus is that they're not moving it out of /trunk/phase3. It probably will move from maintenance/tests/ to just tests/. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Removing test suites from trunk
I'm the first to add a vote to https://bugzilla.wikimedia.org/show_bug.cgi?id=26259 ! Hope it gets counted. M> SVN is convenient for installations and upgrades. That's certainly M> why I use it. Me too. Please move all the expert testing stuff to a different place where the experts can use an expert command to fetch it, and stop bloating we regular WikiSysops SVN updates. Thanks. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Removing test suites from trunk
> > I think the idea that only people intending to do development work on > MediaWiki download from SVN is a bit insane. And as you note, these tests > are only going to grow in size over time. This whole discussion is bringing an analogy to a PHP framework that I'm using a lot now, symfony [1]. Their SVN is even larger than MediaWiki's. A large part of that is for languages (which, by the way, are not only languages, but every single culture too), and lots of unit tests. 99.99% of users don't need them, but they package them anyway. I think that the whole discussion should be moot, as 40MB is not that much in comparison to other codebases. Either way, people will need far more than 40MB of space on the server to run a good wiki, and not very many people have a server that would have less in the first place. -X! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
