Re: [Wikitech-l] Proposal: switch to HTML 5
On Wed, Jul 8, 2009 at 3:46 AM, Gregory Maxwell gmaxw...@gmail.com wrote: There is only a short period of time remaining where a singular browser recommendation can be done fairly and neutrally. Chrome and Opera will ship production versions and then there will be options. Choices are bad for usability. We should not recommend Chrome - as good as it is, but it has serious privacy problems. Opera is not Open Source, so I think we'd best stay with Firefox, even if Chrome/Opera begin to support video tag. Marco -- VMSoft GbR Nabburger Str. 15 81737 München Geschäftsführer: Marco Schuster, Volker Hemmert http://vmsoft-gbr.de ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: switch to HTML 5
On Wed, Jul 8, 2009 at 4:43 PM, Marco Schusterma...@harddisk.is-a-geek.org wrote: We should not recommend Chrome - as good as it is, but it has serious privacy problems. Out of curiosity, why do we need to recommend a browser at all, and why do we think anyone will listen to our recommendation? People use the browser they use. If the site they want to go to doesn't work in their browser, they'll either not go there, or possibly try another one. They're certainly not going to change browsers just because the site told them to. Personally, I use Chrome, FF and IE. And the main reason for switching is just to have different sets of cookies. Occasionally a site doesn't like Chrome, so I switch. But it's not like I'm going to take a your experience would be better in browser statement seriously. Steve ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [WikiEN-l] MediaWiki is getting a new programming language
Steve Bennett wrote: On Tue, Jul 7, 2009 at 5:01 AM, wjhon...@aol.com wrote: The reason BASIC was and still enjoys wide popularity is because it's easier to learn. The example does not make the substantial point because it veers so strongly to the opposite end of the spectrum as to be unrelated to the argument whatsoever. I never suggested that a language should *mimic* English (or a bizarre type of hyper-English). I welcome however, anyone who wants to actually conduct this argument, on Earth. The difference between this thread and the parallel one on wikitech-l: that thread quickly focussed on four genuine candidates: Lua, Python, JavaScript and PHP. People identified the basic requirements (security, speed...) and pointed out the pros and cons of each language, in terms of available interpreters, tried and tested experiments with sandboxing each, etc. Here, we're talking about bringing back BASIC because it's so much more readable. *yawn* Steve Can we take this discussion back to wikitech-l now, please, and focus on specific, concrete proposals for syntax reform and/or language replacement? -- Neil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [WikiEN-l] MediaWiki is getting a new programming language
Gerard Meijssen wrote: Hoi, The argument that a language should be readable and easy to learn is REALLY relevant and powerful. A language that is only good for geeks is detrimental to the use of MediaWiki. Our current templates and template syntax are horrible. Wikipedia is as a consequence hardly editable by everyone. Thanks, GerardM I agree. Could you make some concrete suggestion about how you would go about improving it? -- Neil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Proposals for template language reform
In the spirit of supplying concrete examples, here are my proposed
changes to the syntax of the existing language:
* the existing {{{parm}}} or {{{parm|default}}} notation should be
changed to ${parm} or ${parm|default}
* all newlines and other multiple whitespace characters within template
source code should be regarded as reduced to single spaces, with
explicit calls to {{newline}} and {{whitespace}} operators to generate
explicit whitespace on output
These two changes alone would greatly increase the readability of
templates, both by massively reducing the number of curly brackets
within templates, and by allowing them to be formatted in a clearly
nested and indented form.
If I could add one more change, it would be an {{apply}} function, to
allow explicit calls to other templates whose names have themselves been
generated by template substitution, as used extensively in templates
such as {{coord}}; this would help clean up the semantics of the
underlying language a bit more, allowing further changes to be made more
easily both to the syntax and implementation, and also possibly allowing
a faster implementation that does not require SNOBOL-like re-parsing of
generated text.
-- Neil
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [WikiEN-l] MediaWiki is getting a new programming language
wjhon...@aol.com wrote:
My entire point Neil was simply that, short-time-to-learn should also be a
consideration.? To me, a language that borrows heavily from an *already
known* source like English or even BASIC is easier to learn, than one which
requires that every command be learned again without any prior foundation.? I
am not a subscriber to tech.? I don't think I want to be.
Wikitech-l is undoubtedly the right forum for this discussion, so we
really should continue this discussion there.
I find it rather difficult to understand exactly what you want here.
Could you please give an example, even a rough one, of the sort of
syntax you are proposing?
For example, how would you write something like, say, this artificial
example:
{{#switch:
{{#iferror: {{#expr: {{{1}}} + {{{2}}} }} | error | correct }}
| error = that's an error
| correct = {{{1}}} + {{{2}}} = {{#expr: {{{1}}} + {{{2}}}
in your new notation?
-- Neil
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposals for template language reform
Neil Harris wrote:
* all newlines and other multiple whitespace characters within template
source code should be regarded as reduced to single spaces, with
explicit calls to {{newline}} and {{whitespace}} operators to generate
explicit whitespace on output
Just to clarify this a bit more: this whitespace compression would only
apply to whitespace contained within the template source itself:
whitespaces in text introduced from parameters or other inputs would be
preserved without compression.
-- Neil
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] secure slower and slower
Steve Bennett wrote: On Tue, Jul 7, 2009 at 11:35 PM, William Allen Simpsonwilliam.allen.simp...@gmail.com wrote: Some may not think that this site is critical, or valuable, or whatever. That's a horrible strawman argument. Some simply think that the amount of damage that can be caused by hijacking a non-admin account is fairly low. Maybe for admins the risk is higher. Pretty much all damage is reversible though. You are the person that I'd had in mind, based on your actual comment: # Yeah, and so what? OMG THEY MADE EDITS UNDER MY ACCOUNT. # Thus, not a strawman at all However, (assuming you are a developer) that makes 2 developers indicating this is not a priority. Please remove the link to the secure server on the login page, so that common editors are not confused by it, thinking that this is a supported service I've given you some timing notes, and some error messages. Let us all know about future improvements, should they ever happen. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [WikiEN-l] MediaWiki is getting a new programming language
On Wed, Jul 8, 2009 at 10:16, Gerard Meijssengerard.meijs...@gmail.com wrote: The argument that a language should be readable and easy to learn is REALLY relevant and powerful. A language that is only good for geeks is detrimental to the use of MediaWiki. Our current templates and template syntax are horrible. Wikipedia is as a consequence hardly editable by everyone. Mortals _use_ the templates, not _create_ them. Geeks create templates for mortals. Current syntax is indeed horrible, but complete readibility is not the main issue I'd say. Security, speed and flexibility should be, along the ease of implementation. Peter ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] On templates and programming languages
Aryeh Gregor wrote: On Fri, Jul 3, 2009 at 3:13 AM, Tim Starlingtstarl...@wikimedia.org wrote: Loops are essential for readable code. There is no problem with allowing loops in conjunction with time limits, that we don't have already with complex templates. In fact, time limits for complex templates would be an improvement over the system of expansion limits we have at the moment. But time limits are inconsistent. Whether a template hits the limit might depend on whether it happens to be running on an Apache with a Pentium IV, an Opteron, a Xeon, . . . That's the reason I went with expansion limits when I wrote the code. But I think it was the wrong choice, because the code is complex and there are lots of ways to run over the 30s time limit set in php.ini, or to exceed the memory limit, even with the expansion limits in place. It's hard to find all the potential performance problems during code review, especially when new parser functions are constantly added. I didn't say either method was perfect, just that time limits are better. Recursion can give a long running time even if the depth is limited. By calling the function multiple times from its own body, you can have exponential time order in the recursion depth. You can also have exponential time with loops. Without the time limit, the worst case running time for a JavaScript script is infinity with finite input, so the time order is O(∞). With the time limit, it's O(1). That's the whole point, a time limit lets you ignore algorithmic complexities. If you measure script execution times, instead of trying to guess them in advance, then you can concentrate developer effort on quotas, access control, profiling tools, etc., which I think are more tractable problems than analysing the performance every possible thing the parser can do and limiting it in advance. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposals for template language reform
Neil Harris wrote:
In the spirit of supplying concrete examples, here are my proposed
changes to the syntax of the existing language:
* the existing {{{parm}}} or {{{parm|default}}} notation should be
changed to ${parm} or ${parm|default}
I'm not sure that would actually be parsed. And I'm no fan of leading $,
left over from the variety in PERL.
PHP isn't a model syntax that we should employ.
Actually, as the triple brace syntax is older than the parser functions,
I've never found them to be a problem. And since whitespace is already
compressed (to nothing) in the argument portion of parser functions,
I've never had a problem with adding some whitespace; that is:
{{#if: {{{1|}}}
|
|
}}
My recent surprise was the elimination of leading and trailing *newlines*
in the then and else portions, apparently only in subst'd templates,
behaving *differently* than transclusion. See my thread:
subst'ing #if parser functions loses line breaks, and other oddities
That thread spawned these later discussions.
* all newlines and other multiple whitespace characters within template
source code should be regarded as reduced to single spaces, with
explicit calls to {{newline}} and {{whitespace}} operators to generate
explicit whitespace on output
Since they are already reduced to nothing, that's a given.
I do like the idea of explicit functions {{#line:}} and {{#space:}}, with
parameters indicating the number (that is, {{#line:2}} and {{#space:2}}).
Or {{LINE:}} and {{SPACE:}} or {{LINES:}} and {{SPACES:}} or
This would compliment existing magic words {{padleft:}} and {{padright:}}.
These two changes alone would greatly increase the readability of
templates, both by massively reducing the number of curly brackets
within templates, and by allowing them to be formatted in a clearly
nested and indented form.
If I could add one more change, it would be an {{apply}} function, to
allow explicit calls to other templates whose names have themselves been
generated by template substitution, as used extensively in templates
such as {{coord}}; this would help clean up the semantics of the
underlying language a bit more, allowing further changes to be made more
easily both to the syntax and implementation, and also possibly allowing
a faster implementation that does not require SNOBOL-like re-parsing of
generated text.
Didn't the new parser fix that problem? Besides, SNOBOL was nifty... Once
upon a time, I was proficient. (Now, I'm not sure I remember the syntax
some 30 years later.)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Regular expressions searching
Micke Nordin hett schreven: Amir E. Aharoni amir.aharoni at gmail.com writes: Mostly i was interested to find out whether there is an existing script that searches dumps, instead of writing one myself. I wrote a c++-program that can search through a databasedump (with regexes), it's one of the first apps I wrote, so the source is not pretty to read. You can find it here: http://meta.wikimedia.org/wiki/User:Micke/WikiFind I would not implement it that way (and I would not write it in c++ :), if I was to write it to day, but if you are helped by it please go ahead and use it. Use the second version of the program if you want to pipe the dump in from bzcat. /Micke I tried to install it, but I couldn't manage. If somebody has managed to compile a Vista executable I would appreciate, if he could send me the file. Thanks Marcus Buck User:Slomox ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] On templates and programming languages
Another idea thrown against a wall: can template scripts be pre-calculated ? I think most people talk about script interpreted on-demand. But what If scripts are updated every 100 uses, and in a async way. That way a script that take 10 min to finish is not a problem. It will be updated every 10 min (or every 1 hour, if the servers want that). I mean, have outdated templates, that only updated wen the server can, and not everytime the server use that template. note: I have no idea if this message is more noise to make the raise/signal worst. Sorry if is that. -- -- ℱin del ℳensaje. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] secure slower and slower
On 08/07/2009, at 12:13 PM, William Allen Simpson wrote: However, (assuming you are a developer) that makes 2 developers indicating this is not a priority. Please remove the link to the secure server on the login page, so that common editors are not confused by it, thinking that this is a supported service Expanding the role of secure access to the site for privileged users is one of our ongoing priorities, you should not take the word of two random people involved in MediaWiki development (nor mine, for that matter) on a server issue such as that. If you want something done other than endless argument over the use of SSL on Wikimedia projects, you should file a bug in bugzilla, and assign it to Brion (br...@wikimedia.org) or Rob (rhals...@wikimedia.org), who are actually maintaining that part of the site. -- Andrew Garrett agarr...@wikimedia.org http://werdn.us ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] secure slower and slower
Andrew Garrett wrote: Expanding the role of secure access to the site for privileged users is one of our ongoing priorities, you should not take the word of two random people involved in MediaWiki development (nor mine, for that matter) on a server issue such as that. Thank you. I'd no idea these were random people, as I've seen considerable traffic about development from each. It seemed they were writing authoritatively. And Brion didn't respond. If you want something done other than endless argument over the use of SSL on Wikimedia projects, you should file a bug in bugzilla, and assign it to Brion (br...@wikimedia.org) or Rob (rhals...@wikimedia.org), who are actually maintaining that part of the site. Will do. Was unaware bugzilla was being used for server and operational issues, those used to be the province of this list. And I'm willing to help as much as I can ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: switch to HTML 5
On Wed, 2009-07-08 at 00:59 +0100, David Gerard wrote: 2009/7/7 Brion Vibber br...@wikimedia.org: We don't want to annoy users, but subtle nudges to a better experience can be good. :) (It'd be good to avoid the This site best viewed in Netscape Gold sort of browser fanboy wars of the '90s, though. ;) I know we can't do it, but I do have subtle dreams of Sorry, this video won't display in Safari because Apple refuse to. If you don't want to use a better browser, here's Apple's phone number. - d. I'm not sure I'd call that subtle... Effective maybe :D A little Did you know Firefox 3.5 can show this to you better, get it here notice would be great. Take care to avoid browser fanboy wars yes, but it's be nice to nudge gently. Probably text-only and dismissible would be fine. -Mike ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] secure slower and slower
On Wed, Jul 8, 2009 at 9:05 AM, David Gerarddger...@gmail.com wrote: 2009/7/7 Aryeh Gregor simetrical+wikil...@gmail.com: But really -- have there been *any* confirmed incidents of MITMing an Internet connection in, say, the past decade? Real malicious attacks in the wild, not proof-of-concepts or white-hat experimentation? I'd imagine so, but for all people emphasize SSL, I can't think of any specific case I've heard of, ever. It's not something normal people need to worry much about, least of all for Wikipedia. Nope. The SSL threat model is completely arse-backwards. It assumes secure endpoints and a vulnerable network. Whereas what we see in practice is Trojaned endpoints and no-one much bothering with the network. Actually, there is a lot of screwing with the network. For instance, take the UK service providers surreptitiously modifying Wikipedia's responses on the fly to create a fake 404 when you hit particular articles. I believe it's a common practice for US service providers to sell information feeds about user's browsing data (believe because I know it's done, but don't have concrete information about how common it is). Your use of Wikipedia likely has less privacy than your use of a public library. SSL kills these attacks dead. People whom try to read via Tor to avoid the above mentioned problems subject themselves to naughty activities by unscrupulous exit operators. MITM activities by Tor exit operators are common and well documented. SSL would remove some of the incentive to use Tor (since your local network/ISP could no longer spy on you if you used SSL) and would remove most of Tor's grievous hazard for those who continue to use it to read. There are some truly nasty things you can do with an enwiki admin account. They can be undone, sure, but a lot of damage can be done. They are obvious enough, and have been discussed in backrooms enough that I don't think I'll do much harm by listing a few of them: (1) By twiddling site JS you can likely knock any site off the internet by scripting clients to connect to the sites frequently. Although this can be deactivated once it was discovered, due to caching it would hang around for a while. Well timed even a short outage could cause significant dollar value real damage. (2) You could script clients to kick users to a malware installer. Again, it could be quickly undone, but a lot of damage could be caused with only a few minutes of script placement. Generally you could use WP as a nice launching ground for any kind of XSS vulnerability that you're already aware of. Any of these JS attacks could be enhanced by only making them effective for anons, reducing their visibility, and by making the JS modify the display of the Mediawiki: pages to both hide the bad JS from users and to make it impossible to remove without disabling client JS. Provided your changes didn't break the site, I'd take a bet that you could have a malware installer running for days before it was discovered. (3) You could rapidly merge page histories for large numbers of articles, converting their histories into jumbled messes. I don't believe we yet have any automated solution to fix that beyond restore the site from backups. (4) Any admin account can be used to capture bureaucrat and/or checkuser access by injecting user JS to one of these users and using it to steal their session cookie (unless the change to SUL stopped this, but I don't see how it could have; even if so you could remote pilot them). With checkuser access you can quickly dump out decent amounts of private data. The leak of private data can never be undone. (or, alternatively, you can just MTIM a real steward, checkuser, or bureaucrat (say, at wikimania or a wiki meetup :) ) and get their access directly). These are just a few things… I'm sure if you think creatively you can come up with more. The use of SSL makes attacks harder and some types of attack effectively impossible. It should be considered important. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] secure slower and slower
2009/7/8 Gregory Maxwell gmaxw...@gmail.com: On Wed, Jul 8, 2009 at 9:05 AM, David Gerarddger...@gmail.com wrote: Nope. The SSL threat model is completely arse-backwards. It assumes Actually, there is a lot of screwing with the network. For instance, take the UK service providers surreptitiously modifying Wikipedia's responses on the fly to create a fake 404 when you hit particular articles. *cough* OK, I'm completely wrong :-) - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] secure slower and slower
On Wed, Jul 8, 2009 at 10:45 AM, Gregory Maxwellgmaxw...@gmail.com wrote: (3) You could rapidly merge page histories for large numbers of articles, converting their histories into jumbled messes. I don't believe we yet have any automated solution to fix that beyond restore the site from backups. Quite possibly the only sysop activity (afaik?) that cannot be reversed yet. Merging the top-revisioned articles on enwiki in less than a minute before anyone catches on (certainly doable) would cause such a massive clusterfuck. Without relying on a backup to restore to, it would require inspection of almost every edit in that page's history to make sure they get restored properly. I've thought of this issue before, and it's probably the single most damaging thing that could be done with a sysop account (to the wiki itself, this isn't including JS subtleties and external resources). -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: switch to HTML 5
Aryeh Gregor wrote: On Tue, Jul 7, 2009 at 4:46 PM, Brion Vibberbr...@wikimedia.org wrote: Technically HTML 4 is pretty much the same in this regard; it's 100% legitimate SGML and HTML 4 to skip implied opening and closing elements, drop quotes on attribute values that are unambiguous, etc. Not entirely. HTML 4 doesn't allow you to omit quotes on attribute values that contain non-name characters, for instance, at least according to the W3C validator -- so you need quotes for all URLs, for example. These aren't necessary either in practice, or in HTML 5. I'm pretty sure the requirements for opening and closing elements are stricter in HTML 4 as well. Remember Postel's robustness principle (paraphrased): be conservative in what you send, liberal in what you accept If quotes are always permitted, then always send the quotes. If closing tags are always permitted, then always send the tags. The browsers will handle them, and we don't need to worry about the flavor of browser. There's no need to over-optimize the output. The intended viewer isn't human, and we're not talking about enough extra characters that very slow links will be congested HTML 5 tends to loosen things up to whatever all browsers support, which is usually more lenient than what HTML 4 formally allows. It also actually specifies what constructs must be supported, in painstaking detail, so you can figure out what's legal without dumping it in a validator and hoping the validator's correct . . . Great. Does that mean HTML 5 browsers will still accept formal HTML 4? Then, let's stick to the stricter interpretation. On Tue, Jul 7, 2009 at 4:49 PM, Brion Vibberbr...@wikimedia.org wrote: XML formulation could perhaps be useful if we migrate page text storage from custom markup to an HTML-based internal format, as we could then toss it at XML parsers without worrying. But that doesn't have any bearing on the HTML user interface we display to end-users in browsers. Does that mean go ahead and begin switching to HTML 5 now, or what? My thought is that the 5 tags that are marked as well-supported could be used, but be very cautious about abandoning 4. There are a lot of old machines out there, and many cannot upgrade to newer browsers, because they cannot upgrade their underlying operating systems. For example: schools, already heavy *pedia users. And political campaigns often use cast-off machines. Win98 or 2K means no upgrades. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: switch to HTML 5
I'm only considering the projects I was going to work on and can't talk for all the things MediaWiki team should have in mind - I was going to add support for RDFa (http://www.w3.org/TR/rdfa-syntax/) which currently is W3C Recomendation, but only for XHTML and even though HTML profiles (or whatever they are called) are in the works they are not ready yet. Switching to non-recomendation will mean that implementing RDFa in standard compliant form will have to be postponed for quite a while. As for commotion I mentioned, I believe there is at least tension between RDFa world and Microdata world that is being pushed along HTML 5 spec. Thank you, Sergey -- Sergey Chernyshev http://www.sergeychernyshev.com/ On Tue, Jul 7, 2009 at 2:46 PM, Aryeh Gregor simetrical+wikil...@gmail.comsimetrical%2bwikil...@gmail.com wrote: On Tue, Jul 7, 2009 at 2:29 PM, Sergey Chernyshevsergey.chernys...@gmail.com wrote: Just my 2 cents - I don't think that switching to new not yet W3C Recomendation is a good idea - many extensions and features are not yet finished (e.g. RDFa support for it) Much of the spec is very stable. We would not be using any part that's likely to change -- in most cases, only parts that have multiple interoperable implementations. Such parts of the spec will not change significantly; that's a basic principle of most W3C specs' development processes (and HTML 5's in particular). We use other W3C specs that nominally aren't stable, e.g., some parts of CSS. We used plenty of CSS 2.1 when that was still nominally a Working Draft. We use multi-column layout (at least in our content on enwiki) even though that's a Working Draft. Etc. Given the way the W3C works, it's not reasonable at all to require that the *whole* spec be a Candidate Recommendation or whatever. You can make a feature-by-feature stability assessment pretty easily in most cases: if it has multiple interoperable implementations, it's stable and can be used; if it doesn't, it's not very useful anyway, so who cares? and considering a huge commotion in this area it might not be a very good decision. There is no more commotion. XHTML 2.0 is officially dead. The working group is disbanded. HTML 5 is the only version of HTML that is being developed. I don't think you've raised any substantive objections here. *Practically* speaking, what reason is there not to begin moving to HTML 5 now? ___ 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] secure slower and slower
Gregory Maxwell wrote: For instance, take the UK service providers surreptitiously modifying Wikipedia's responses on the fly to create a fake 404 when you hit particular articles. Urk. (Can someone cite the details?) (2) You could script clients to kick users to a malware installer... ...and to make it impossible to remove without disabling client JS. Remind me why client-side JavaScript is a good idea? (Boy, am I glad I use NoScript.) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] secure slower and slower
2009/7/8 Steve Summit s...@eskimo.com: Gregory Maxwell wrote: For instance, take the UK service providers surreptitiously modifying Wikipedia's responses on the fly to create a fake 404 when you hit particular articles. Urk. (Can someone cite the details?) http://en.wikipedia.org/wiki/Internet_Watch_Foundation_and_Wikipedia - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] secure slower and slower
2009/7/8 David Gerard dger...@gmail.com: 2009/7/8 Steve Summit s...@eskimo.com: Gregory Maxwell wrote: For instance, take the UK service providers surreptitiously modifying Wikipedia's responses on the fly to create a fake 404 when you hit particular articles. Urk. (Can someone cite the details?) http://en.wikipedia.org/wiki/Internet_Watch_Foundation_and_Wikipedia The interesting thing, by the way, is that (a) we spotted the interception *immediately* (b) we spotted a later interception, a month or two later, immediately as well - and the IWF denied involvement in the second interception when we asked them directly (and we have no reason not to believe them on this), suggesting the ISPs in question were testing the CleanFeed filter to see how it affected a major site (we don't actually know the reason, that's the most plausible thing anyone could come up with). This suggests the best thing we can do about this style of censorship is default SSL for all. Which won't be cheap, but would serve our editors well. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: switch to HTML 5
We need to inform people that the quality of experience can be substantially improved if they use a browser that supports free formats. Wikimedia only distributes content in free formats because if you have to pay for a licensee to view, edit or publish ~free content~ then the content is not really ~free~. We have requested that Apple and IE support free formats but they have chosen not to. Therefore we are in a position where we have to recommend a browser that does have a high quality user experience in supporting the formats. We are still making every effort to display the formats in IE Safari using java or plugins but we should inform people they can have an improved experience on par with proprietary solutions if they are using different browser. --michael Steve Bennett wrote: On Wed, Jul 8, 2009 at 4:43 PM, Marco Schusterma...@harddisk.is-a-geek.org wrote: We should not recommend Chrome - as good as it is, but it has serious privacy problems. Out of curiosity, why do we need to recommend a browser at all, and why do we think anyone will listen to our recommendation? People use the browser they use. If the site they want to go to doesn't work in their browser, they'll either not go there, or possibly try another one. They're certainly not going to change browsers just because the site told them to. Personally, I use Chrome, FF and IE. And the main reason for switching is just to have different sets of cookies. Occasionally a site doesn't like Chrome, so I switch. But it's not like I'm going to take a your experience would be better in browser statement seriously. Steve ___ 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] Proposal: switch to HTML 5
On Wed, Jul 08, 2009 at 10:58:43AM -0400, William Allen Simpson wrote: My thought is that the 5 tags that are marked as well-supported could be used, but be very cautious about abandoning 4. There are a lot of old machines out there, and many cannot upgrade to newer browsers, because they cannot upgrade their underlying operating systems. For example: schools, already heavy *pedia users. And political campaigns often use cast-off machines. Win98 or 2K means no upgrades. I don't think there is any suggestion that backwards compatibility should be broken. MediaWiki is a project which has strived to keep full compatibility with most browsers since its creation. Robert ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: switch to HTML 5
On Wed, Jul 8, 2009 at 2:23 PM, Michael Dalemd...@wikimedia.org wrote: The current language is For best video playback experience we recommend _Firefox 3.5_ ... but I am open to adjustments. I'd drop the word experience. It's superfluous marketing speak. So the notice chain I'm planning on adding to the simple video/ compatibility JS is something like this: If the user is using safari4 on a desktop system and doesn't have xiphqt: * Advise the user to install XiphQT (note, there should be a good installer available soon) The rational being that if they are known to use safari now they probably will in the future, better to get them to install XiphQT than to hope they'll continue using another browser. If the users is using any of a list of platforms known to support firefox: * Advise them to use firefox 3.5 Otherwise say nothing. It would be silly at this time to be advising users of some non-firefox-supporting mobile device that firefox 3.5 provides the best experience. ;) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: switch to HTML 5
2009/7/8 Michael Dale md...@wikimedia.org: We have requested that Apple and IE support free formats but they have chosen not to. Therefore we are in a position where we have to recommend a browser that does have a high quality user experience in supporting the formats. We are still making every effort to display the formats in IE Safari using java or plugins but we should inform people they can have an improved experience on par with proprietary solutions if they are using different browser. A method that doesn't say your browser sucks but shows it: You are using Safari without XiphQT. Install the Ogg codecs _here_ for a greatly improved Wikimedia experience. You are using Internet Explorer. Install the Ogg codecs _here_ for a greatly improved Wikimedia experience. The first linking to XiphQT, the second to Ogg DirectShow. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Recommending a browser for video (was: Proposal: switch to HTML 5)
On Wed, Jul 8, 2009 at 2:43 AM, Marco Schusterma...@harddisk.is-a-geek.org wrote: We should not recommend Chrome - as good as it is, but it has serious privacy problems. Opera is not Open Source, so I think we'd best stay with Firefox, even if Chrome/Opera begin to support video tag. I don't think we should use these kinds of ideological criteria when making any sort of recommendation here. We should state in a purely neutral fashion that browsers X, Y, and Z will result in the video playing better on your computer than your current browser does. It would be misleading to imply that Firefox is superior to these other browsers for the purposes of playing the video tag. On Wed, Jul 8, 2009 at 2:42 PM, Gregory Maxwellgmaxw...@gmail.com wrote: I'd drop the word experience. It's superfluous marketing speak. So the notice chain I'm planning on adding to the simple video/ compatibility JS is something like this: If the user is using safari4 on a desktop system and doesn't have xiphqt: * Advise the user to install XiphQT (note, there should be a good installer available soon) The rational being that if they are known to use safari now they probably will in the future, better to get them to install XiphQT than to hope they'll continue using another browser. If the users is using any of a list of platforms known to support firefox: * Advise them to use firefox 3.5 Otherwise say nothing. It would be silly at this time to be advising users of some non-firefox-supporting mobile device that firefox 3.5 provides the best experience. ;) That sounds good. Why not recommend Safari plus XiphQT as well, if the goal is only to tell them what browsers support good video playback? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Making local mirror of one of the Wikipedia subdomains.
Hello. I'm not sure if this is appropriate list for such kind of question. I'll appreciate if someone directs me to the proper one. One has task to make a local fully-functional mirror of Wikipedia sudomain (articles, images, etc. must be located on the local server). Currently there are not so many articles and downloading dump once a day may be an option. But there is a problem: how to synchronize changes made to the local copy back to the Wikipedia? Is there any piece of software that could help? I would appreciate any help. Sincerely, Artyom. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: switch to HTML 5
David Gerard wrote: A method that doesn't say your browser sucks but shows it: You are using Safari without XiphQT. Install the Ogg codecs _here_ for a greatly improved Wikimedia experience. You are using Internet Explorer. Install the Ogg codecs _here_ for a greatly improved Wikimedia experience. The first linking to XiphQT, the second to Ogg DirectShow. Internet Explorer does not support the video tag, installing Ogg DirectShow filters does not help there. j ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: switch to HTML 5
2009/7/8 j...@v2v.cc: David Gerard wrote: You are using Internet Explorer. Install the Ogg codecs _here_ for a greatly improved Wikimedia experience. Internet Explorer does not support the video tag, installing Ogg DirectShow filters does not help there. Yes, I realised this just after sending my email :-) I presume, though, there's some way of playing videos in IE. Is there a way to tell if the Ogg filters are installed? - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Recommending a browser for video (was: Proposal: switch to HTML 5)
On Wed, Jul 8, 2009 at 2:56 PM, Aryeh Gregorsimetrical+wikil...@gmail.com wrote: On Wed, Jul 8, 2009 at 2:43 AM, Marco Schusterma...@harddisk.is-a-geek.org wrote: We should not recommend Chrome - as good as it is, but it has serious privacy problems. Opera is not Open Source, so I think we'd best stay with Firefox, even if Chrome/Opera begin to support video tag. I don't think we should use these kinds of ideological criteria when making any sort of recommendation here. We should state in a purely neutral fashion that browsers X, Y, and Z will result in the video playing better on your computer than your current browser does. It would be misleading to imply that Firefox is superior to these other browsers for the purposes of playing the video tag. Not every decision is a purely technical. Mozilla has done a lot to support the development of this functionality. Putting other browser developers on equal footing is not an neutral decision either. The ideological, and other, criteria is moot when there is only one thing to recommend. On Wed, Jul 8, 2009 at 2:42 PM, Gregory Maxwellgmaxw...@gmail.com wrote: That sounds good. Why not recommend Safari plus XiphQT as well, if the goal is only to tell them what browsers support good video playback? Hm. Two things to install rather than one? For the moment there is also a technical problem with Safari 4: It claims (via the canPlayType() call) that it can't support Ogg even when XiphQT is installed. We currently work around this by detecting the mime-type registration which happens as part of the XiphQT installation. In practice this means that Safari 4 will work with Ogg video on sites using OggHandler, but not on many others. Safari also isn't an especially widely adopted browser outside of apple systems. Should we also recommend the dozens of oddball free geko and webkit based browsers supporting video/ which are soon to exist? Flooding the users with options is a good way to turn them off. There is already at least one (Midori). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: switch to HTML 5
You use quicktime + Xiph quicktime components (ie the codec) -Mike On Wed, 2009-07-08 at 20:06 +0100, David Gerard wrote: 2009/7/8 j...@v2v.cc: David Gerard wrote: You are using Internet Explorer. Install the Ogg codecs _here_ for a greatly improved Wikimedia experience. Internet Explorer does not support the video tag, installing Ogg DirectShow filters does not help there. Yes, I realised this just after sending my email :-) I presume, though, there's some way of playing videos in IE. Is there a way to tell if the Ogg filters are installed? - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposals for template language reform
On Wed, Jul 8, 2009 at 8:04 AM, William Allen Simpsonwilliam.allen.simp...@gmail.com wrote: I'm not sure that would actually be parsed. And I'm no fan of leading $, left over from the variety in PERL. PHP isn't a model syntax that we should employ. Didn't the Bourne shell use a $ prefix for all variables, a decade before Perl existed? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: switch to HTML 5
2009/7/8 Gregory Maxwell gmaxw...@gmail.com: Since, at the moment, firefox is the only non-beta browser with direct support I don't see why plugging Firefox would be controversial. It's a matter of fact that it works best with Firefox 3.5 or Safari+XiphQT. Later when there are several options things will be a little more complicated. Certainly I don't think any recommendation should be made when the user already has native-grade playback. Yeah. Recommend XiphQT or Firefox to Safari users, Firefox to all others. iPhone users, get 'em to call Apple? Seriously, what polite wording do we use to politely get across to iPhone users that this is 100% Apple's express decision to break Ogg video? Probably an idea to run this past foundation-l for sanity checking - this would be perceived by the outside world as Wikimedia getting involved (which it most assuredly is). - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Recommending a browser for video (was: Proposal: switch to HTML 5)
Gregory Maxwellgmaxw...@gmail.com wrote: For the moment there is also a technical problem with Safari 4: It claims (via the canPlayType() call) that it can't support Ogg even when XiphQT is installed. We currently work around this by detecting the mime-type registration which happens as part of the XiphQT installation. In practice this means that Safari 4 will work with Ogg video on sites using OggHandler, but not on many others. Oh yes, I forgot that bug. Until Apple release the fix for that, there's nothing to do but feed 'em Cortado and strongly suggest Firefox. Safari also isn't an especially widely adopted browser outside of apple systems. Should we also recommend the dozens of oddball free geko and webkit based browsers supporting video/ which are soon to exist? Flooding the users with options is a good way to turn them off. There is already at least one (Midori). Link to a page? The Wikimedia Foundation has worked closely with the Mozilla Foundation on Firefox 3.5. The following will also work ... - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: switch to HTML 5
On Wed, Jul 8, 2009 at 3:06 PM, David Gerarddger...@gmail.com wrote: 2009/7/8 j...@v2v.cc: David Gerard wrote: You are using Internet Explorer. Install the Ogg codecs _here_ for a greatly improved Wikimedia experience. Internet Explorer does not support the video tag, installing Ogg DirectShow filters does not help there. Yes, I realised this just after sending my email :-) I presume, though, there's some way of playing videos in IE. Is there a way to tell if the Ogg filters are installed? Java or via the VLC plugin At least the safari + xiphqt has the benefit of working as well as firefox 3.5 does. The same is not true for Java or VLC. (the VLC plugin is reported to cause many browser crashes, Java is slow to launch and somewhat CPU hungry) I've suggested making the same installer for XiphQT for win32 also install the XiphDS plugins, which would make things easier on users. But XiphDS does not help with in-browser playback today. Since, at the moment, firefox is the only non-beta browser with direct support I don't see why plugging Firefox would be controversial. It's a matter of fact that it works best with Firefox 3.5 or Safari+XiphQT. Later when there are several options things will be a little more complicated. Certainly I don't think any recommendation should be made when the user already has native-grade playback. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: switch to HTML 5
On Wed, Jul 8, 2009 at 10:58 AM, William Allen Simpsonwilliam.allen.simp...@gmail.com wrote: Remember Postel's robustness principle (paraphrased): be conservative in what you send, liberal in what you accept This applies only if there's some reason to be conservative. There's no reason to arbitrarily send only a subset of possible markup if every browser that supports that subset will support the full range of markup as well. Restricting ourselves to HTML 4 based on the principle of being conservative in what we send makes no more sense than restricting ourselves to, I don't know, class names that contain only the letters z, f, and q. It won't increase compatibility -- it's just a pointless inconvenience. If quotes are always permitted, then always send the quotes. If closing tags are always permitted, then always send the tags. The browsers will handle them, and we don't need to worry about the flavor of browser. There is *no* flavor of browser that requires quotes or closing tags. None. I'd be willing to bet there's not a single one released in the last ten years that ever attained more than 0.1% overall market share, say. Any browser that did things like requiring quotes or closing tags would *completely* *break* the web. It wouldn't display a majority of websites correctly, and nobody would use it. This is a fact. (In any event, HTML 4 doesn't require either quotes or closing tags in all circumstances, although it requires them more often than HTML 5 does.) There's no need to over-optimize the output. The intended viewer isn't human, and we're not talking about enough extra characters that very slow links will be congested We're talking about a few percent difference in size, for almost no effort on our part. And I would say that it definitely is a slight plus if the HTML is more human-readable. What are the concrete downsides? Great. Does that mean HTML 5 browsers will still accept formal HTML 4? Then, let's stick to the stricter interpretation. All browsers are HTML 5 browsers in the sense of not requiring quotes or closing tags when HTML 5 doesn't require them. Those parts of HTML 5 are just reverse-engineered from existing behavior that's been de facto standard since early in the IE-Netscape wars, at least. My thought is that the 5 tags that are marked as well-supported could be used, but be very cautious about abandoning 4. There are a lot of old machines out there, and many cannot upgrade to newer browsers, because they cannot upgrade their underlying operating systems. For example: schools, already heavy *pedia users. And political campaigns often use cast-off machines. Win98 or 2K means no upgrades. Nothing I have proposed will have even the smallest negative impact on anyone's ability to view Wikipedia in a web browser, even with very old browsers. The only negative effect will be on non-web-browser users, who we don't want screen-scraping anyway. On Wed, Jul 8, 2009 at 11:15 AM, Sergey Chernyshevsergey.chernys...@gmail.com wrote: I'm only considering the projects I was going to work on and can't talk for all the things MediaWiki team should have in mind - I was going to add support for RDFa (http://www.w3.org/TR/rdfa-syntax/) which currently is W3C Recomendation, but only for XHTML and even though HTML profiles (or whatever they are called) are in the works they are not ready yet. Switching to non-recomendation will mean that implementing RDFa in standard compliant form will have to be postponed for quite a while. I'm pretty sure this will be resolved within a matter of months, one way or another. Either Ian will cave and support RDFa, or RDFa will support HTML 5 (at least in a usable draft form) without HTML 5's explicit agreement, or microdata will gain support as wide as RDFa. At worst, you can still use MW 1.15 while things are being worked out. Or maybe we could provide a switch to allow HTML 5 or XHTML, but I'm leery of that, since it negates most of the benefits. I admit that I don't follow RDF and semantic web stuff too closely, so I'm not very qualified to address this objection. I'm pretty sure that RDFa support is not an issue for the overwhelming majority of our users, however. On the other hand, improved video support and better form handling for a significant percentage of our users are examples of clear and concrete benefits from HTML 5. Is this actually a *practical* problem even for the very small number of users who want to use RDFa? I mean, will RDFa really not work with HTML 5 in practice, or will it work but it's not standardized? As for commotion I mentioned, I believe there is at least tension between RDFa world and Microdata world that is being pushed along HTML 5 spec. Yes, there definitely is tension there! Just not between HTML 5 and XHTML 2 -- that's over, even if a few people might not have gotten the message yet. I don't know what will happen with RDFa vs. microdata. I find it unlikely
Re: [Wikitech-l] Making local mirror of one of the Wikipedia subdomains.
On Wed, Jul 8, 2009 at 3:40 PM, Jens Frankj...@mormo.org wrote: On Thu, Jul 09, 2009 at 12:01:32AM +0500, Artyom Sokolov wrote: One has task to make a local fully-functional mirror of Wikipedia sudomain (articles, images, etc. must be located on the local server). Currently there are not so many articles and downloading dump once a day may be an option. But there is a problem: how to synchronize changes made to the local copy back to the Wikipedia? Is there any piece of software that could help? Don't do that. Synchronizing back is a very difficult task, and you will find yourself in deep trouble very soon. If you don't do proper replication conflict resolution, you'll have either junk on your side or on the Wikipedia side. In the later case, you'll probably get blocked rather soon, in the other case your users will get frustrated because their edits don't get through. Regards, jens ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Using dumps locally for an offline version is pretty easy to set up (download the right dump, import with either importDump or mwdumper). Syncing changes back to the live site is a Very Bad Idea, like Jens said. There is absolutely no supported mechanism to do this (see bugs 2054 and 15468). -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] secure slower and slower
On Wed, Jul 8, 2009 at 7:13 AM, William Allen Simpsonwilliam.allen.simp...@gmail.com wrote: However, (assuming you are a developer) that makes 2 developers indicating this is not a priority. Please remove the link to the secure server on the login page, so that common editors are not confused by it, thinking that this is a supported service Steve Bennett is not a developer (as far as I can tell). And while I am a developer, I'm not a sysadmin and have nothing to do with configuring or maintaining the secure server. As a general rule, I've found that with open-source stuff you usually can't tell apart the decision-makers from random opinionated hangers-on without actually doing research or asking . . . it's kind of annoying, but fun! :) For what it's worth, I also don't think SSL is worthless. I don't personally see any reason to go out of my way to use it, and think it's a little odd for someone else to do that given the marginal benefit it would provide by any metric. But I'd definitely agree that if it could be enabled for all Wikipedia users by *default* that would be great. A small benefit times millions of users can be a very big benefit. An ideal Internet would encrypt *and* sign all communications with no opt-out. (One of the things I'm looking forward to if Google Wave takes off!) On Wed, Jul 8, 2009 at 10:45 AM, Gregory Maxwellgmaxw...@gmail.com wrote: Provided your changes didn't break the site, I'd take a bet that you could have a malware installer running for days before it was discovered. What, on enwiki? I'd bet ten minutes before it's noticed someone using NoScript configured to prompt about cross-site loads or something. (Maybe not if it just includes an image for DoS purposes, but then the target would notice soon enough, you'd think . . .) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Recommending a browser for video (was: Proposal: switch to HTML 5)
On Wed, Jul 8, 2009 at 3:32 PM, Gregory Maxwellgmaxw...@gmail.com wrote: Not every decision is a purely technical. Mozilla has done a lot to support the development of this functionality. Putting other browser developers on equal footing is not an neutral decision either. I think the most neutral thing would be to suggest the top two or three browsers for the platform that support the functionality, in order of market share. If the browser has negligible (1%?) market share on the platform, or only supports video in beta or development builds, it can be left off. Maybe you could also put Safari second even on Mac, since it requires an extra install and doesn't work perfectly. But I think it's misleading to act as though Safari isn't a good option, when it's the default system browser and probably works better in various other ways than Mac Firefox (I've definitely heard that this was the case before Firefox 3.0). If the message made it clear that the recommendation was opinionated, and not just advising the viewer on how best to view the video, it would be less of an issue to exclude browsers for not being open-source or whatever. Like We recommend you use X, which will allow you to view this video better instead of X will allow you to view this video better. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Recommending a browser for video (was: Proposal: switch to HTML 5)
On Wed, Jul 8, 2009 at 4:27 PM, David Gerarddger...@gmail.com wrote: Uh, it's not a good option for Wikimedia video. With XiphQT, why not? Maybe not ideal, but surely good. And, more importantly, it's not a good option for Wikimedia video because Apple has *deliberately chosen to make it not a good option*. They haven't prevented it from being an option. As far as I know, Safari is the only video-implementing browser with pluggable codec support. I haven't bothered doing any research, so I could be wrong -- maybe Chrome or Opera support pluggable codecs -- but Firefox definitely does not let you use codecs other than Theora, unless I'm badly mistaken. The upshot is that Safari is certainly the second-best stable browser to view Theora video on. They seriously think everyone should just use H.264. No one from Apple has ever said that. They are not willing to ship support for Theora directly themselves, that's all. And they may be willing to reconsider: http://lists.xiph.org/pipermail/theora/2009-July/002415.html Nothing Apple has done has suggested to me that they've acted dishonestly. Everything I've seen is consistent with them perceiving not enough benefit from supporting Theora to justify taking a nontrivial (although not necessarily large) legal risk. Of course, their actions also might be consistent with more sinister hypotheses, but let's not assume bad faith here, shall we? Regardless, if the message is phrased purely as advice on how to get videos working better, what it says should *not* follow any motives other than that. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: switch to HTML 5
On Wed, Jul 8, 2009 at 11:15 AM, Sergey Chernyshevsergey.chernys...@gmail.com wrote: I'm only considering the projects I was going to work on and can't talk for all the things MediaWiki team should have in mind - I was going to add support for RDFa (http://www.w3.org/TR/rdfa-syntax/) which currently is W3C Recomendation, but only for XHTML and even though HTML profiles (or whatever they are called) are in the works they are not ready yet. Switching to non-recomendation will mean that implementing RDFa in standard compliant form will have to be postponed for quite a while. I'm pretty sure this will be resolved within a matter of months, one way or another. Either Ian will cave and support RDFa, or RDFa will support HTML 5 (at least in a usable draft form) without HTML 5's explicit agreement, or microdata will gain support as wide as RDFa. At worst, you can still use MW 1.15 while things are being worked out. Or maybe we could provide a switch to allow HTML 5 or XHTML, but I'm leery of that, since it negates most of the benefits. I admit that I don't follow RDF and semantic web stuff too closely, so I'm not very qualified to address this objection. I'm pretty sure that RDFa support is not an issue for the overwhelming majority of our users, however. On the other hand, improved video support and better form handling for a significant percentage of our users are examples of clear and concrete benefits from HTML 5. I see your point - video is clearly more popular then RDFa and if you're willing to go off-standard to support it, it's might be a reasonable decision for a site like Wikipedia. Not sure what is the rush for that and why can't it wait till HTML 5 spec becomes a recommendation. I'm not that familiar with HTML 5 support in modern browsers to state that there are going to be regressions with some other things, but it might be another thing to consider, although Wikipedia might be big enough to be a driving force in such decisions. Is this actually a *practical* problem even for the very small number of users who want to use RDFa? I mean, will RDFa really not work with HTML 5 in practice, or will it work but it's not standardized? Sorry, can't give you a definitive answer - CCing RDFa list for this. Guys, will be happy if you provide where RDFa support stands here. As for commotion I mentioned, I believe there is at least tension between RDFa world and Microdata world that is being pushed along HTML 5 spec. Yes, there definitely is tension there! Just not between HTML 5 and XHTML 2 -- that's over, even if a few people might not have gotten the message yet. I don't know what will happen with RDFa vs. microdata. I find it unlikely that anyone will convince Ian to include RDFa at this point with just arguments. But if it sees much wider adoption than microdata, he'd probably include it. ___ 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] Recommending a browser for video (was: Proposal: switch to HTML 5)
2009/7/8 Aryeh Gregor simetrical+wikil...@gmail.com: On Wed, Jul 8, 2009 at 4:27 PM, David Gerarddger...@gmail.com wrote: Uh, it's not a good option for Wikimedia video. With XiphQT, why not? Maybe not ideal, but surely good. As Greg has noted, due to a bug in Safari it's impossible for the browser at present to indicate that it can handle Ogg or not. So how do we tell if the Safari user can use that or if they have to download XiphQT? There isn't a way at present. Either we shove Safari on Mac users onto Cortado by default (since Java can be presumed present on MacOS X) or we risk giving them a video element that doesn't work. (Unless the failure can somehow be sniffed.) Nothing Apple has done has suggested to me that they've acted dishonestly. Everything I've seen is consistent with them perceiving not enough benefit from supporting Theora to justify taking a nontrivial (although not necessarily large) legal risk. Of course, their actions also might be consistent with more sinister hypotheses, but let's not assume bad faith here, shall we? They are happy to foul up the entire standard. I feel there is little to no benefit to us in trying to imply that the situation is otherwise. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] secure slower and slower
On Wed, Jul 8, 2009 at 10:04 PM, Aryeh Gregor simetrical+wikil...@gmail.comsimetrical%2bwikil...@gmail.com wrote: On Wed, Jul 8, 2009 at 10:45 AM, Gregory Maxwellgmaxw...@gmail.com wrote: Provided your changes didn't break the site, I'd take a bet that you could have a malware installer running for days before it was discovered. What, on enwiki? I'd bet ten minutes before it's noticed someone using NoScript configured to prompt about cross-site loads or something. And if you're not a real technical expert who sees aha, the site where the js comes from is surely NOT wikipedia, it doesn't help anyone. People click away these warnings very often and don't bother to actually read them... this is something most people forget in security themes. Marco -- VMSoft GbR Nabburger Str. 15 81737 München Geschäftsführer: Marco Schuster, Volker Hemmert http://vmsoft-gbr.de ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Recommending a browser for video (was: Proposal: switch to HTML 5)
On Wed, Jul 8, 2009 at 6:12 PM, David Gerarddger...@gmail.com wrote: 2009/7/8 Aryeh Gregor simetrical+wikil...@gmail.com: On Wed, Jul 8, 2009 at 4:27 PM, David Gerarddger...@gmail.com wrote: Uh, it's not a good option for Wikimedia video. With XiphQT, why not? Maybe not ideal, but surely good. As Greg has noted, due to a bug in Safari it's impossible for the browser at present to indicate that it can handle Ogg or not. So how do we tell if the Safari user can use that or if they have to download XiphQT? There isn't a way at present. Either we shove Safari on Mac users onto Cortado by default (since Java can be presumed present on MacOS X) or we risk giving them a video element that doesn't work. (Unless the failure can somehow be sniffed.) Well *we* do. As a side effect of installing XiphQT a mime type is registered. This is completely independent of the video tag. So we'll detect this and use it anyways. I believe we're the only users of video whom have ever done this. It's not obvious, and I doubt we'd be doing it were it not for the fact that that detection method was previously used for detecting pre-video availability of XiphQT. (FWIW, that behaviour is now fixed in their development builds) Regardless, I think we've finished the technical part of this decision— the details are a matter of organization concern now, not technology. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: switch to HTML 5
On Wed, Jul 8, 2009 at 5:41 PM, Sergey Chernyshevsergey.chernys...@gmail.com wrote: I see your point - video is clearly more popular then RDFa and if you're willing to go off-standard to support it, it's might be a reasonable decision for a site like Wikipedia. Not sure what is the rush for that and why can't it wait till HTML 5 spec becomes a recommendation. The HTML 5 FAQ has useful info on this: http://wiki.whatwg.org/wiki/FAQ See especially When will HTML 5 be finished? and When will we be able to start using these new features? HTML 5 likely will not reach even *Candidate* Recommendation stage until 2012, and might take until 2020 or later to get to Recommendation status. It's a very large spec, and there's absolutely no reason not to use the parts that are fully fleshed out, implemented, and stable just because some other parts are less stable. As I said before, we've always done this with CSS; and this is the official position of the ones responsible for writing and implementing the HTML 5 specification. I'm not that familiar with HTML 5 support in modern browsers to state that there are going to be regressions with some other things, but it might be another thing to consider, although Wikipedia might be big enough to be a driving force in such decisions. We are talking about using only polished, finalized features that are implemented in stable browsers which have undergone considerable testing. Unless you can point out specific problems that might arise, there's no reason to anticipate more risk of unexpected problems with HTML 5 than with any other new type of functionality we deploy. There might hypothetically be some useful things that work in XHTML 1 but not HTML 5, but there are *definitely* a number of useful things that work in HTML 5 but not XHTML 1, which have already been outlined in this thread. (And in practice, the WHATWG has made a point of incorporating all unequivocally useful features from XHTML in some form.) Keep in mind that changing MediaWiki to output valid HTML 5 (modulo GIGO) instead of XHTML 1 on a normal page view would probably take under 20 lines of code changes. I could do it in five minutes. This is an *extremely* small change. Each specific feature of HTML 5 that we use after that can be evaluated for deployment on a case-by-case basis, just as we'd evaluate any other new technology like web fonts or RDFa. If problems do arise from switching to HTML 5 per se, it would be easy to change back to XHTML. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Defining a configuration for regression testing
I am setting up a testing environment for mediawiki and the first thing that came to mind is testing new extensions against a regression test configuration. That raises the question of what should constitute such a configuration. One issue is which extensions should be loaded. There are over 2000 extensions in the mediawiki extensions matrix and 512 stable extensions. It would be impractical to run a configuration with all of either class. So, I asked around and received a suggestion that at the very least the extensions on the wikimedia servers should be loaded. I went to http://noc.wikimedia.org/conf/ and copied CommonSettings.php. From it I extracted 75 extensions that are used on wikimedia's servers. I list these below. A question for readers of this list is: should a regression test configuration load only these extensions or should it load others? Another question is: what other settings should define a regression test configuration. Wikimedia installed extensions: Timeline, wikihiero, SiteMatrix, CharInsert, CheckUser, SpecialMakesysop, Makebot, ParserFunctions, Cite, InputBox, ExpandTemplates, ImageMap, SyntaxHighlight_GeSHi, DoubleWiki, Poem, PovWatch, AjaxTest, UnicodeConverter, CategoryTree, ProofreadPage, lst, SpamBlacklist, UploadBlacklist, TitleBlacklist, Quiz, Gadgets, OggHandler, AssertEdit, FormPreloadPostCache, SkinPerPage, Schulenburg, Tomas, ContributionReporting, ContributionTracking, ContactPage, ExtensionDistributor, GlobalBlocking, TrustedXFF, ContactPage, SecurePoll, OAIRepo, DynamicPageList, Nogomatch, SpecialCrossNamespaceLinks, SpecialRenameuser, SpecialNuke, AntiBot, TorBlock, CookieBlock, ScanSet, SpecialCite, FixedImage, UserThrottle, ConfirmEdit, FancyCaptcha, HideRevision, AntiSpoof, CentralAuth, DismissableSiteNotice, UsernameBlacklist, MiniDonation, CentralNotice, TitleKey, WikimediaMessages, SimpleAntiSpam, Collection, NewUserMessage, CodeReview, Drafts, Configure, AbuseFilter, ClientSide, CommunityVoice, PdfHandler, UsabilityInitiative Regards, Dan Nessett ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Recommending a browser for video (was: Proposal: switch to HTML 5)
On Wed, Jul 8, 2009 at 6:12 PM, David Gerarddger...@gmail.com wrote: They are happy to foul up the entire standard. I feel there is little to no benefit to us in trying to imply that the situation is otherwise. First of all, Apple is not fouling up the entire standard. They employ one of its two co-editors, their developers contribute to it very actively, and they ship an implementation that's as advanced as anybody's. This is *one* specific feature that they've said they won't implement at the present time (but they may reconsider at any time). Mozilla has vetoed features as well, as Ian Hickson has pointed out. Mozilla refused to implement SQL, so that was removed from the standard, just as mention of Theora was. Second of all, I don't have a serious problem with Wikimedia only advocating the use of open-source software, say. But if it does, it *must* be phrased in a way that makes it clear that it's an advertisement of a product we want the user to use, not a neutral assessment of what the best technology is for viewing the page. Anything else is deliberately misleading, and that's unacceptable. On Wed, Jul 8, 2009 at 6:21 PM, Gregory Maxwellgmaxw...@gmail.com wrote: Regardless, I think we've finished the technical part of this decision— the details are a matter of organization concern now, not technology. Yep, definitely. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposals for template language reform
Aryeh Gregor wrote: On Wed, Jul 8, 2009 at 8:04 AM, William Allen Simpsonwilliam.allen.simp...@gmail.com wrote: I'm not sure that would actually be parsed. And I'm no fan of leading $, left over from the variety in PERL. PHP isn't a model syntax that we should employ. Didn't the Bourne shell use a $ prefix for all variables, a decade before Perl existed? Not sure, as I've been using Unix since late 1977, so my fingers mostly remember csh. The $ is something like contents of variable. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposals for template language reform
On Wed, Jul 8, 2009 at 8:56 PM, William Allen Simpsonwilliam.allen.simp...@gmail.com wrote: Not sure, as I've been using Unix since late 1977, so my fingers mostly remember csh. The $ is something like contents of variable. It's a way to distinguish variables from ordinary text. Shell scripts, like wikitext, don't require string delimiters, so you can't just make unadorned strings of letters represent variables. Other ad hoc macro languages, like mIRC script, also tend to use some kind of sigil for this reason. Perl might have come up with the idea of using sigils to distinguish different types of variables, but that's not the only reason they're useful. According to Wikipedia, BASIC may have used sigils for that purpose before anyone else used them, though: string variables use $, numeric variables don't. And that's well before Unix, apparently, let alone sh or Perl. Using sigils for wikitext would increase readability and would serve a perfectly useful purpose, while being familiar to many users. But you couldn't introduce it on old pages, they'd have to opt in somehow. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Inconsistent math markup fonts within a single text section
Sorry if this is not the correct forum to report a possible bug. I noticed browsing the Example of second-order singular perturbation theory section of the Perturbation Theory page on wikipedia: --- Consider the following equation for the unknown variable mathx/math: :mathx=1+\epsilon x^5./math For the initial problem with math\epsilon=0/math, the solution is mathx_0=1/math. For small math\epsilon/math the lowest order approximation may be found by inserting the [[ansatz]] :mathx=x_0+\epsilon x_1 (+\cdots)/math -- that the markup fonts of x in each of the :math sections are different. In particular there are no serifs on the top x's in the first equation and x_0=1 on my Linux box. On the others, there are small serifs. I don't see why they should be rendering differently. The ascii certainly doesn't indicate anything to me... I've tested this on: IE7.0 Windows Safari 4.0 on OSX 10.5 Firefox 3.5 on OSX 10.5 Firefox 3.0.10 on Linux 2.6.18-128.1.10.el5 I've attached a small screenshot of what I see. M ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Inconsistent math markup fonts within a single text section
On Wed, Jul 8, 2009 at 9:19 PM, Michael Kaufmankauf...@physics.wisc.edu wrote: that the markup fonts of x in each of the :math sections are different. In particular there are no serifs on the top x's in the first equation and x_0=1 on my Linux box. On the others, there are small serifs. All the math is displayed in a serif font for me (Chromium 3.0.192.0 (0) on Linux). Of course, since it's italics, they aren't standard straight serifs, but it's visibly a serif font nonetheless. Obviously, one of those math things is an image, not text, so that one looks different. All the equations are wrapped in span class=texhtml, which renders them in a serif font. I've attached a small screenshot of what I see. Attachments to this list are stripped. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Inconsistent math markup fonts within a single text section
On Wed, Jul 08, 2009 at 09:32:04PM -0400, Aryeh Gregor wrote: On Wed, Jul 8, 2009 at 9:19 PM, Michael Kaufmankauf...@physics.wisc.edu wrote: All the math is displayed in a serif font for me (Chromium 3.0.192.0 (0) on Linux). Of course, since it's italics, they aren't standard straight serifs, but it's visibly a serif font nonetheless. Obviously, one of those math things is an image, not text, so that one looks different. All the equations are wrapped in span class=texhtml, which renders them in a serif font. Ah, I should have looked at the page source, rather than just the wiki source. I am guessing that too-complicated math is TeX rendered into an image, but less complicated math is handled by the html? Well, a quick lesson. Thanks. M ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] On templates and programming languages
Steve Sanbeg wrote: On Fri, 03 Jul 2009 17:13:45 +1000, Tim Starling wrote: Recursion can give a long running time even if the depth is limited. By calling the function multiple times from its own body, you can have exponential time order in the recursion depth. All those calls still end up on the same stack; even if it could be a tree in theory, the stack only grows one way, and execution time would only be linear. That's an interesting theory. I found some documentation on the example I'd thought of emulating, which may clarify a little: http://www.delorie.com/gnu/docs/elisp-manual-21/elisp_123.html I thought I would try it. (defun pow5 (n) (if (= n 0) 1 (+ (pow5 (1- n)) (pow5 (1- n)) (pow5 (1- n)) (pow5 (1- n)) (pow5 (1- n)) ) ) ) It calculates 5 to the power of n by adding 1+1+1+1+1... I found that with a stack depth limit of 25, I was able to calculate 5^6 = 15625. That's plainly not an O(N) execution time in stack depth. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making local mirror of one of the Wikipedia subdomains.
Don't do that. Synchronizing back is a very difficult task, and you will find yourself in deep trouble very soon. If you don't do proper replication conflict resolution, you'll have either junk on your side or on the Wikipedia side. In the later case, you'll probably get blocked rather soon, in the other case your users will get frustrated because their edits don't get through. Regards, jens At one wiki site (not a Wikipedia) an improved version of Special:Ancientpages is used to manually synchrolize between localhost and webhost clone wiki sites. This version of Special:Ancientpages allows to select another exportable namespaces besides NS_MAIN and optionally submits these to Special:Export. By default, the functionality of Special:Export is very limited (at least it was last time I was cheking it). A better approach probably would be introducing an --date option to maintenance/dumpBackup.php. The important problem though is, that during XML import not all hooks are called and extension-specific data is not saved/restored correctly :-( I think it's major problem that these hooks doesn't allow to pass their own XML tags into the dumps. Dmitriy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
