Re: [Wikitech-l] ResourceLoader, now in trunk!
PHP Path-info made this work, despite being horribly broken.
Fixed in r72355. Thanks for poking!
- Trevor
On 9/3/10 9:43 PM, Q wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 9/3/2010 10:59 PM, Trevor Parscal wrote:
- Trevor (and Roan, who's committing the merge to SVN right now)
Pssst, it's broken.
- --
var src=mediaWiki.config.get('server')+'/load.php
- --
Hurm, what's server?
mediaWiki.config.get('server')
http://www.thedarkcitadel.com/w/load.php;
http://www.thedarkcitadel.com/w/load.php/load.php = 404 = broken
legacy scripts = no working JavaScript
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBCAAGBQJMgc5/AAoJEL+AqFCTAyc2LEMIAKQaeR9jMLXdXE+s366n2Sj/
HHW6Wu8bJ8gQ60gMdF1RYkIFWQLRfVyb63vl5cw4QinhBdOHrkXzzicfy7UhGqcf
JWNeAb/qF8y+ZBb4HI2af6OdvHoGhow4udzB2yUGIShhQEPpTfnHNFgR0M/mMo8L
5jhyizIaVc/yWo0EeYQG4RTU4BzjyQCWZlR/bFksCLpgyQ/deF/voPL2XFGRUPXR
31/lOlG8+9BiT741AbFsUNaa6VhFH0iZ/5UExigs/9HyJwq/E9lcBTQow3mIEXXN
oYWOAX/AXmE80E+VclVSh7DqEGiLZSVBX8RW4kGCJr9Fj+KzQhvEGsGEDuS7yro=
=LHAO
-END PGP SIGNATURE-
___
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] ResourceLoader, now in trunk!
On 4 September 2010 06:59, Trevor Parscal tpars...@wikimedia.org wrote: MediaWiki Developers, * Right-to-left support in CSS is akward. Stylesheets for right-to-left must to be either hand-coded in a separate stylesheet, generated each time a change is made by running CSSJanus, or an extra style-sheet which contains a series of over-rides. * Performs automatic left-to-right/right-to-left flipping for CSS files. In most cases the developer won't have to do anything before deploying. Does this affect in any way the possibility of fixing the long-standing LTR-RTL problem, where page direction depends on the content language? It should depend on the user language instead, and it should be possible to have content in different direction. Or is this just automation of the work which was previously done by hand or not done at all? -Niklas -- Niklas Laxström ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [HTML5] Improving Commons upload interface
Marcus Buck w...@marcusbuck.org wrote in message news:4c81a467.7070...@marcusbuck.org... I didn't deem any project unnecessary and I didn't pick any holes. All the projects are useful. But if I say I'd like more focus on project X and the answer is our resources are limited and we want to work on projects Y and Z first than my options are to either provide more resources (which I can't) or to argue that X is more important than Z. I have tried to argue for the projects that I feel are important on several occasions, but the answer was yeah, nice idea, do it yourself. Putting feature requests on Bugzilla is ineffective too (https://bugzilla.wikimedia.org/show_bug.cgi?id=164 exists since 2004 and still people invest thousands of working hours removing diacritics in category sorting keys). And that's why I made suggestions to focus more on development of features. I think that's pretty much the crux of it. You have been trying to opine that X is more important than Z, and not, in the general opinion, succeeding. You certainly make the case that X is important, we generally all agree on that. Numerous people have explained why various Z, which you have tried to portray as less important, are in fact either vital for the Foundation's continued operation, or more closely aligned with the Foundation's goals and will achieve more for the amount of time and money which must be spent on them. Ultimately, you haven't provided any concrete argument why X is *relatively* more important than Y or Z. You won't achieve that by talking up the merits of X and talking down the merits of Z, that's not a *relative* comparison. Why is CentralInterwiki more important *than*, say, LiquidThreads?? I'm not convinced that that's a question which can be sensibly debated, in either direction; and without it, this thread isn't really going anywhere interesting. --HM ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ResourceLoader, now in trunk!
When you combine ResourceLoader's ability to flip css on the fly with changes made in r72366, what you are asking for should work with just a bit more tweaking. r72367 and 72368 make strides towards solving the issue of going to Arabic Wikipedia and using English as your language, ensuring we don't just flip on RTL, we flip when the user language is not the same direction as the content language, and only do this for CSS hosted on the wiki. Unfortunately because site CSS is still not passed through ResourceLoader this is not a complete solution. - Trevor On 9/4/10 1:11 AM, Niklas Laxström wrote: On 4 September 2010 06:59, Trevor Parscaltpars...@wikimedia.org wrote: MediaWiki Developers, * Right-to-left support in CSS is akward. Stylesheets for right-to-left must to be either hand-coded in a separate stylesheet, generated each time a change is made by running CSSJanus, or an extra style-sheet which contains a series of over-rides. * Performs automatic left-to-right/right-to-left flipping for CSS files. In most cases the developer won't have to do anything before deploying. Does this affect in any way the possibility of fixing the long-standing LTR-RTL problem, where page direction depends on the content language? It should depend on the user language instead, and it should be possible to have content in different direction. Or is this just automation of the work which was previously done by hand or not done at all? -Niklas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [HTML5] Improving Commons upload interface
Marcus Buck wrote:
I have a whole list of features that we lack. Another one is better
multilingual support. Commons is multilingual, but the software doesn't
support multilingualism on content pages well. Commons created a whole
bunch of rather esoteric templates to work around the limitations of
MediaWiki. Template:ISOdate is used to render dates in a localized
format. It's used on 6.5 million pages and it's logic is rather complex.
I guess it would be a big performance gain for Commons if MediaWiki
would natively support the functionality of ISOdate.
Marcus Buck
User:Slomox
I don't see there was any bug requesting that.
Can you make a list of the templates that would be replaced?
That would be {{ISOdate}}, {{date}}, {{I18n month}}, what else?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ResourceLoader, now in trunk!
On 09/04/2010 05:59 AM, Trevor Parscal wrote: Over the past couple of months, Roan Kattouw and I (Trevor Parscal) have been working on a JavaScript and CSS delivery system called ResourceLoader. We're really excited about this technology, and hope others will be too. Cool! There have been many complaints with the introduction of Vector that Wikimedia sites are taking longer to load, hopefully this will be fixed soon. :) signature.asc Description: OpenPGP digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ResourceLoader, now in trunk!
On 9/4/10 8:31 AM, Platonides wrote: church.of.emacs.ml wrote: On 09/04/2010 05:59 AM, Trevor Parscal wrote: Over the past couple of months, Roan Kattouw and I (Trevor Parscal) have been working on a JavaScript and CSS delivery system called ResourceLoader. We're really excited about this technology, and hope others will be too. Cool! There have been many complaints with the introduction of Vector that Wikimedia sites are taking longer to load, hopefully this will be fixed soon. :) It will be interesting to see the reactions for the sites which get vector and the resourceloader at the same time. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Well, given we've recently switched all projects to Vector (are there any we have yet to switch that I don't know of?) that's not really possible anymore. - Trevor ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ResourceLoader, now in trunk!
Well, given we've recently switched all projects to Vector (are there any we have yet to switch that I don't know of?) that's not really possible anymore. We could try asking someone from outside Wikimedia :p Conrad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [HTML5] Improving Commons upload interface
An'n 04.09.2010 16:16, hett Platonides schreven:
Marcus Buck wrote:
I have a whole list of features that we lack. Another one is better
multilingual support. Commons is multilingual, but the software doesn't
support multilingualism on content pages well. Commons created a whole
bunch of rather esoteric templates to work around the limitations of
MediaWiki. Template:ISOdate is used to render dates in a localized
format. It's used on 6.5 million pages and it's logic is rather complex.
I guess it would be a big performance gain for Commons if MediaWiki
would natively support the functionality of ISOdate.
Marcus Buck
User:Slomox
I don't see there was any bug requesting that.
Can you make a list of the templates that would be replaced?
That would be {{ISOdate}}, {{date}}, {{I18n month}}, what else?
Depends what you want to solve, the whole complex of Commons
localisation or just the dates. Relevant templates for dates are
Template:Formatnum
Template:FormatnumDigit
Template:ISOyear
Template:Time
Template:Other date
Template:Date-time separator
I think that's it.
Marcus Buck
User:Slomox
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Community vs. centralized development
Στις 03-09-2010, ημέρα Παρ, και ώρα 05:34 -0700, ο/η Conrad Irwin έγραψε: On 3 September 2010 00:51, Danese Cooper dcoo...@wikimedia.org wrote: 1. Eliminate single points of failure / bottlenecks 2. Reconfigure into teams designed to encourage faster (shorter duration) and more accurate projects / deployments 3. Develop programs to encourage / grow volunteers into paid staff...recognizing that as a non-profit WMF needs to plan for more frequent turnover in the Tech department to ensure that we can grow expertise across the dev community rather than concentrating it in a few core people. 4. Restore the balance between community-led and foundation-led efforts so WMF feels again like a partnership rather than concentric circles of permission / blame I really like item 2. When I was working on MediaWiki related stuff, the main problem I had was working out who to talk to. The answer, if you ask, seems always to be Tim — which is not very scalable (brilliant though Tim is). I'd hope that along with an organisation into more formal teams would come a structure where individuals are responsible (either permanently, or on rotation like the chromium) for subsets of MediaWiki/Wikimedia. I think of the who to talk to issue (which in part reduces to a who can officially sign off on your code so it may be deployed issue) as #1, bottlenecks. Over the past few years that I have been involved in various ways in the Wikimedia projects, I have seen people give up after waiting a couple of years for their code to make to the deployable stage. This in term impacts both #3 (getting/attracting volunteers who can later turn into paid staff) and #4 (dynamics between WMF and the community, to the extent that WMF staff are not considered community members. It sort of puts a new spin on the old If you want it done, write it yourself because we are too busy line. When writing it yourself (and being willing to revise it until it's considered good) isn't available as an option any more, an open source project is rather less open. I know that is by no means the only bottleneck we have; it's just the one that looms large in my mind at the moment. This would imply that the structure used by the Usability Initiative is something we want to emulate — a few tight-knit teams that can focus on specific concerns, containing people with the power to say yes or no to particular features/ideas. Having a person responsible for saying no is essential; as Danese says, you can't accept every random patch or idea that gets thrown your way, and leaving things languishing forever is less kind than just saying no (ideally with a reason). Hiding behind team decisions is impersonal to the point of rudeness — if I'm committing into your area of interest, I am part of your team. Having teams responsible (and with authority) for different areas, able to approve features and code, sounds fabulous. I know we are moving towards broader team structure already. Ideally there might be more than one person on each team who could give the thumbs up/down. The other advantage of having teams is that it makes it more explicit which areas of development are being focussed on, and by whom. Wikimedia obviously concentrates a reasonable amount on fundraising, which is essential as a means, but it doesn't achieve anything directly. I'd hope that having some kind of explicit structure would expose any less obvious blind-spots — my personal gripe is that no time gets spent on Wiktionary (cf. bug 20246). Clearly there are downsides, cliques are likely to form. I'd certainly regard it as a failure of the system if it stopped someone from doing something merely because they were currently on the wrong team — there's not much point in keeping lists of team members, perhaps all that is needed is a team leader (responsible for accepting or refusing changes/ideas), and the team is simple those who are talking to him. In case it's not obvious, I would not make team leaders exclusively employees, but use the meritocracy previously described that would only make it likely that most of them would be. The other sentiment I very much agree with is that more communication should be public — for the simple reason that if I don't know what you're doing, I can't help. Keeping track (however loosely) of what's being worked on is much more efficient than trying to second guess. If the channels we have are too noisy, it's easy to split them by topic. I like the idea of making #mediawiki the support channel, and having #mediawiki-dev for development — this is a model used by lots of projects on freenode. We could even have #mediawiki-offtopic too, if people want to do a lot of misc chatting. Being able to talk to other developers is very useful for getting things done, whereas having some developers who can't be contacted at all by others is very troublesome indeed. I had assumed that it was a requirement for
[Wikitech-l] list of proposed fundraising stimuli (was Re: fundraising...)
Ryan Kaldari wrote: ... [we're] in the process of hooking up Open Web Analytics http://www.openwebanalytics.com It's great to see that donor logs are going in to a database instead of just a text file, but multiple regression in SQL is absurdly difficult because of the limitations of SQL, so I still recommend R, in particular: http://cran.r-project.org/web/packages/RMySQL/RMySQL.pdf and http://wiener.math.csi.cuny.edu/Statistics/R/simpleR/stat006.html I will ask Arthur Richards for data coding formats. I predict that multiple response checkboxes will do better than the more constraining radio buttons, but there is no reason that they should not be measured as any other independent variable. It is probably a lot more important to measure the number of earmarks offered: 0-26. There is plenty of reason to believe that showing 26 options will have a slight advantage over 25, but I can't see the test results from the Red Cross (they measure the things which increase donations of blood much more carefully than money, at least in their publications that I've been able to find.) Don't forget the control case where no donor selections are offered. Optimization requires measurement, and it is easy to measure offering a lot of options up front. Do you think that variations on the disclaimer should also be tried? I think there is reason to believe something terse might result in more donations, e.g.: These options are advisory only. and/or The Wikimedia Foundation reserves the right to override donor selections, cancel any project, and use any funds for any purpose. and/or All donations are discretionary, these options are offered for polling purposes only. or some combination. What does Mike Godwin think a good set of disclaimers to test might be? I conflated the proposed stimulus list down to 25 non-default items and enumerated them with letters of the alphabet so that everyone would understand that it is feasible to test additional proposals as well. I have not yet surveyed the Village Pumps or mailing lists for additional stimulatory ideas but I hope people who have or who see anything missing will suggest at least five more. Translations would be great, too. (default) Use my donation where the need is greatest. A. Auction the order of search failover links to search engine companies. B. Broaden demographics of active editors. C. Compensate people who submit improvements to the extent that they are necessary and sufficient. D. Display most popular related articles. E. Enhance automation of project tasks. F. Enhance site performance in underserved geographic regions. G. Enhance visualizations of projects and their editing activity. H. Establish journalism awards, expense accounts and compensation for independent Wikinews reporters, fact checkers, photographers and proofreaders. I. Establish secure off-site backup copies. J. Establish simple Wikipedias for beginning readers in languages other than English. K. Improve math formula rendering. L. Increase the number of active editors. M. Increase the number of articles, images, and files. N. Increase the number of unique readers. O. Make it easier for people to add recorded audio pronunciations. P. Obtain expert article assessments. Q. Obtain reader quality assessments. R. Perform external code reviews. S. Perform independent usability testing. T. Produce regular snapshots and archives. U. Retain more active editors. V. Strengthen Wikimedia Foundation financial stability. W. Support a thriving research community. X. Support an easier format to write quiz questions. Y. Support more reliable server uptime. Z. Support offline editing. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] list of proposed fundraising stimuli (was Re: fundraising...)
On 4 September 2010 23:26, James Salsman jsals...@gmail.com wrote: I conflated the proposed stimulus list down to 25 non-default items and enumerated them with letters of the alphabet so that everyone would understand that it is feasible to test additional proposals as well. I have not yet surveyed the Village Pumps or mailing lists for additional stimulatory ideas but I hope people who have or who see anything missing will suggest at least five more. Translations would be great, too. To point out what is probably obvious but can always do with reiteration: Whatever is in this list will be run through an English-Moron translator, twice, then become a news story in that form. Particularly in the next couple of months. Trust me on this one - we are (a) incredibly famous and mainstream (b) the space-filling option of choice on a slow news day.[*] Whatever is done here will be garbled, misunderstood and misconstrued then spread around the world in that form. So do please do this, but run it past everyone first :-) [*] http://www.independent.co.uk/life-style/gadgets-and-tech/news/wikipedia-springs-mousetrap-ending-2064958.html - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
