[Wikitech-l] Mediawiki and html5
Hi, I've heard that wikipedia will be among the first content providers to support the video and audio tags in html5. I'm trying to put up a presentation about the subject for a FF3.5 release party and I would like to find out more. Could you point me to some documents or answer some of the questions below? 1) When will this support appear? 2) Has the code already been modified accordingly? 3) How much time will legacy browsers be supported? 4) What prompted this desire to be an early adopter of this technology? 5) Will other codecs except Theora be supported? I know some of these questions have already been answered, either here or on the techblog (which BTW is currently down), but I thought putting them all toghether would make more sense. Thanks, Andrei Cipu [aka Strainu] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Mediawiki and html5
On Sat, Jun 27, 2009 at 6:39 PM, Strainu wrote: > > 1) When will this support appear? > 2) Has the code already been modified accordingly? The Wikimedia sites all have the OggHandler extension installed, which supports a number of different methods for playing audio and video, including the and tags: http://www.mediawiki.org/wiki/Extension:OggHandler A button is displayed (along with a thumbnail for video), which runs some javascript when clicked to detect a method to play the media. If the user's browser supports the and tags, they will be used. Otherwise, the script steps through various browser plugin media players (starting with the Cortado Java applet) until it finds one that works, or if there is none, directs the user to where they can download one. I'm using FF 3.5 and video playback works very nicely, using the tags. > 3) How much time will legacy browsers be supported? As long as the OggHandler extension is used, playback will try to devolve gracefully. -- Stephen Bain stephen.b...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Mediawiki and html5
On Sat, Jun 27, 2009 at 4:39 AM, Strainu wrote: > Hi, > > I've heard that wikipedia will be among the first content providers to > support the video and audio tags in html5. I'm trying to put up a > presentation about the subject for a FF3.5 release party and I would > like to find out more. Could you point me to some documents or answer > some of the questions below? > > 1) When will this support appear? > 2) Has the code already been modified accordingly? Stephen Bain addressed this admirably, but I thought I should add that the support has been there for years now. We've been waiting browser vendors to catch up. Even prior to Opera's push for the video tag we had in-browser java based playback of Ogg files on English Wikipedia. > 3) How much time will legacy browsers be supported? For Wikimedia legacy browser support is fairly inexpensive: They play back the same files that the video/audio users. So legacy support can last as long as its relevant. For sites who have used other formats for legacy browsers, they have the cost of maintaining another set of encodes and format royalties, so for them there may be more incentive to drop legacy support. There is also a question of what constitutes 'legacy': There is one desktop browser can play our video perfectly adequately using the HTML5 tags, but it requires a codec pack. > 4) What prompted this desire to be an early adopter of this technology? Wikimedia has a long-standing commitment to open and unencumbered file formats which stems back to nearly the start of the projects. The mission of the Wikimedia Foundation is "to empower and engage people around the world to collect and develop educational content under a free license or in the public domain, and to disseminate it effectively and globally", and it has been the belief that people are more empowered when they don't feel forced for compatibility reasons to use formats they have to ask permission for and pay for. As such, the use of encumbered video technology such as flash is not something that would be decided lightly. The adoption of the HTML5 tags follows naturally from this pre-existing behavior as a way of getting media working for a larger portion of the userbase. > 5) Will other codecs except Theora be supported? The list of file types supported today can be found here: http://commons.wikimedia.org/wiki/Commons:File_types Really the support just depends on the intersection of the project requirements (as of today: free and unencumbered formats) and client support (as of today, Ogg/Theora has the widest client compatibility for HTML5 video). The thumbnailing infrastructure for video currently only handles Ogg/Theora but other formats could be easily added. This one isn't really a technical question. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extending wikilinks syntax
Victor Vasiliev wrote: > I suggest to use for external links extended syntax and parametrized > [[]] for internal links so we can easily distinguish them. > --vvv Kalan explained it "s may be used by spammers, by the way." A talk page gets added the text 'This page explains it pretty well http://example.com";>some webpage' Currently, you see the html garbage, realise at first sight that it's a spambot and revert. If were an accepted syntax, you would doubt if it's spam or a person trying to use wikisyntax. It's sad not being able to use the logical tag, but I oppose making valid the spammers messages. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Downloading using mwdumper
Abhishek wrote: > Hi, > > I'm looking to download the "wiki-latest-stub-meta-history.xml" for smaller > languages and perform some analytics on it. I dont really care about the > english > wikipedia because its too large to handle. I want a csv file made out of this > xml so that i can do stats modelling on it. > > The trouble is I ve been unable to convert this xml to a csv so far. If i can > get this to sql then phpmyadmin can spit out a csv. But mwdumper has failed. > I've gotten the following error (copied below) > > Thanks in advance, > Abhishek I don't think the tables sql is appropiate. Maybe -page.sql fits you. What columns do you want on your csv? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Enabling some string functions
Brian wrote:
> They want the functionality and they are willing to satisfy usability and
> quality of implementation in order to get it, plain and simple.
> ParserFunctions combined with StringFunctions is flat out unreadable. We
> should not facilitate the writing of unreadable code.
>
> As an example, yesterday I wrote some code that basically says, "check the
> doi and http template parameters and check to make sure they begin with
> http, and if not add it." In any reasonable sort of language that lends
> itself to a reasonable sort of implementation. But not with Parser and
> String Functions.
>
> #[[{{{1}}}]].
> {{#if:{{{4}}}|[|{{#if:{{{5}}}|[{{#if:{{#pos:{{#if:{{{4}}}|{{{4}}}|{{#if:{{{5}}}|{{{5}}}|http|}}|{{#if:{{{4}}}|{{{4}}}|{{#if:{{{5}}}|{{{5}}}|{{#if:{{{4}}}|
> http://dx.doi.org/{{{4}}}|{{#if:{{{5}}}|http://dx.doi.org/{{{5}
> {{#if:{{{2}}}| {{{2}{{#if:{{{4}}}|]|{{#if:{{{5}}}|] {{#ifexist:
> File:{{{1}}}.pdf |[{{filepath:{{{1}}}.pdf}} (PDF)]|}} {{#if:{{{3}}}|
> ''{{{3}}}.''}}
>
> There is some extra stuff in there, but you get my point. Just because a few
> people really, really want extra functionality at any cost doesn't mean
> much.
I have seen this before.
People use #if for everything even when there is a better way.
Look at what you're doing:
{{#if:{{{4}}}|{{{4}}}|{{#if:{{{5}}}|{{{5}}}
{{#if:{{{5}}}|{{{5}}} mean "show parameter 5 if it is set", or
"show parameter 5 if it is not blank".
In either case, {{{5|}}} would do the job.
The parent #if is simlar parameter 4 if set, else parameter 5.
{{{4| {{{5|}}} }}} would do the job.
Template default parameters were here much before ParserFunctions.
But people prefer using ugly #ifs, making syntax more unreadable (and
increasing preprocessor limits).
Another common abuse is to do:
{{#if: {{{Foo}}}|
Foo: {{{Foo}}}
}}
I'd like to have a feature in the parser to mark a section to be skipped
if the inner parameter is not set, without having to use #ifs everywhere.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Enabling some string functions
You seem confused. You seem to think that I care about the proper way to
program using templates and parser functions. That's not true, they are an
ugly hack and I recognize that. If have absolutely no desire to learn how to
use something so hideously inefficient in an efficient manner.
On Sat, Jun 27, 2009 at 4:43 PM, Platonides wrote:
> Brian wrote:
> > They want the functionality and they are willing to satisfy usability and
> > quality of implementation in order to get it, plain and simple.
> > ParserFunctions combined with StringFunctions is flat out unreadable. We
> > should not facilitate the writing of unreadable code.
> >
> > As an example, yesterday I wrote some code that basically says, "check
> the
> > doi and http template parameters and check to make sure they begin with
> > http, and if not add it." In any reasonable sort of language that lends
> > itself to a reasonable sort of implementation. But not with Parser and
> > String Functions.
> >
> > #[[{{{1}}}]].
> >
> {{#if:{{{4}}}|[|{{#if:{{{5}}}|[{{#if:{{#pos:{{#if:{{{4}}}|{{{4}}}|{{#if:{{{5}}}|{{{5}}}|http|}}|{{#if:{{{4}}}|{{{4}}}|{{#if:{{{5}}}|{{{5}}}|{{#if:{{{4}}}|
> > http://dx.doi.org/{{{4}}}|{{#if:{{{5}}}|http://dx.doi.org/{{{5}}}
> }}
> > {{#if:{{{2}}}| {{{2}{{#if:{{{4}}}|]|{{#if:{{{5}}}|] {{#ifexist:
> > File:{{{1}}}.pdf |[{{filepath:{{{1}}}.pdf}} (PDF)]|}} {{#if:{{{3}}}|
> > ''{{{3}}}.''}}
> >
> > There is some extra stuff in there, but you get my point. Just because a
> few
> > people really, really want extra functionality at any cost doesn't mean
> > much.
>
> I have seen this before.
> People use #if for everything even when there is a better way.
> Look at what you're doing:
> {{#if:{{{4}}}|{{{4}}}|{{#if:{{{5}}}|{{{5}}}
>
>
> {{#if:{{{5}}}|{{{5}}} mean "show parameter 5 if it is set", or
> "show parameter 5 if it is not blank".
> In either case, {{{5|}}} would do the job.
>
> The parent #if is simlar parameter 4 if set, else parameter 5.
> {{{4| {{{5|}}} }}} would do the job.
>
> Template default parameters were here much before ParserFunctions.
> But people prefer using ugly #ifs, making syntax more unreadable (and
> increasing preprocessor limits).
>
>
>
> Another common abuse is to do:
> {{#if: {{{Foo}}}|
> Foo: {{{Foo}}}
> }}
>
>
> I'd like to have a feature in the parser to mark a section to be skipped
> if the inner parameter is not set, without having to use #ifs everywhere.
>
>
> ___
> 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] Changes to parser - link endings.
Steve Bennett wrote: > On Thu, Jun 25, 2009 at 8:43 PM, Mark Clements > (HappyDog) wrote: >> I noticed the problem here: >> http://en.wikipedia.org/wiki/Neil%27s_Heavy_Concept_Album > > Now that you mention it, that does look marginally odd. Both options > seem pretty reasonable, so unless anyone feels strongly about it, > seems like there is no issue? > > (One slight advantage I see in not linking the "'s" is to slightly > reduce the chance of two consecutive linked phrases. [[John]]'s > [[bike]] is more clearly two separate links. > > Steve So keeep it as it's. Currently, people wanting 's linked can do it using [[Foo|Foo's]] while getting the 's outside would require ugliness like [[Foo]]'s. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Minify
Andrew Dunbar wrote: > This sounds great but I have a problem with making action=raw return > something that is not raw. For MediaWiki I think it would be better to > add a new action=minify > > What would the pluses and minuses of that be? > > Andrew Dunbar (hippietrail) +1 There are uses depending on action=raw to download the wikitext. The proposed new action is autoexplicative, so it seems a good idea. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Minify
On Sat, Jun 27, 2009 at 4:04 PM, Platonides wrote: > Andrew Dunbar wrote: >> This sounds great but I have a problem with making action=raw return >> something that is not raw. For MediaWiki I think it would be better to >> add a new action=minify >> >> What would the pluses and minuses of that be? >> >> Andrew Dunbar (hippietrail) > > +1 > > There are uses depending on action=raw to download the wikitext. > The proposed new action is autoexplicative, so it seems a good idea. Are their uses that depend on dowloanding the wikitext of CSS and JS pages?? The extension only modifies content from CSS and JS pages (e.g. Monobook.css), and then only if the ctype and/or gen query parameter is also specified. It would leave the content from action=raw unchanged in all other cases. Capturing content via action=raw seems necessary since that is the request mechanism used by Skin.php when inserting CSS and JS links. To generate the same effect with "action=minify" would require significant changes to Skin.php, and would seem to go well beyond the scope of a simple extension. -Robert Rohde ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] subst'ing #if parser functions loses line breaks, and other oddities
As this thread has come back, I'd like to take the time to say thank you.
Tisza Gergő wrote:
> Just put the templates on separate lines and wrap the whole thing in another
> #if
> to discard additional newlines at the end:
>
> {{#if:1|
> {subst|}}}#if:{{{par1|1}}}|[[Category:{{{par1}}}{subst|}}}#if:
> {{{key1|1}}}|{subst|}}}!}}{{{key1}]]}}
> {subst|}}}#if:{{{par2|}}}|[[Category:{{{par2}}}{subst|}}}#if:
> {{{key2|}}}|{subst|}}}!}}{{{key2}]]}}
> {subst|}}}#if:{{{par3|}}}|[[Category:{{{par3}}}{subst|}}}#if:
> {{{key3|}}}|{subst|}}}!}}{{{key3}]]}}
> }}
>
> (This assumes that whenever par2 is missing, par3 is missing too.)
>
That worked, and I finally finished the replacements today.
For just the categories, I needed 3 levels of those wrapping #if's.
Elsewhere, I needed 4 levels.
Fortunately, BBedit on a Mac does a good job keeping track of the levels
for balancing {}.
My final code for posterity (aligned, using my emit templates, but not
putting the par test in them yet, which could probably be done to make
the code cleaner) for just the categories -- see the actual 40+ parameter
mess at [[Template:Catdesc wipeout parent categories]]:
{subst|}}}#if:3
|
{subst|}}}#if:1
|
{subst|}}}#if:{{{par1|}}}
|{subst|}}}emit category
|1={{{par1|}}}
|2={{{key1|}}}
|subst={{{subst|}}}
}}
}}
{subst|}}}#if:{{{par2|}}}
|{subst|}}}emit category
|1={{{par2|}}}
|2={{{key2|}}}
|subst={{{subst|}}}
}}
}}
{subst|}}}#if:{{{par3|}}}
|{subst|}}}emit category
|1={{{par3|}}}
|2={{{key3|}}}
|subst={{{subst|}}}
}}
}}
{subst|}}}#if:{{{par4|}}}
|{subst|}}}emit category
|1={{{par4|}}}
|2={{{key4|}}}
|subst={{{subst|}}}
}}
}}
{subst|}}}#if:{{{par5|}}}
|{subst|}}}emit category
|1={{{par5|}}}
|2={{{key5|}}}
|subst={{{subst|}}}
}}
}}
{subst|}}}#if:{{{par6|}}}
|{subst|}}}emit category
|1={{{par6|}}}
|2={{{key6|}}}
|subst={{{subst|}}}
}}
}}
}}
{subst|}}}#if:2
|
{subst|}}}#if:1
|
{subst|}}}#if:{{{dpar1|}}}
|{subst|}}}emit category
|1={{{dpar1|}}}
|2={{{dkey1|}}}
|subst={{{subst|}}}
}}
}}
{subst|}}}#if:{{{dpar2|}}}
|{subst|}}}emit category
|1={{{dpar2|}}}
|2={{{dkey2|}}}
|subst={{{subst|}}}
}}
}}
{subst|}}}#if:{{{dpar3|}}}
|{subst|}}}emit category
|1={{{dpar3|}}}
|2={{{dkey3|}}}
|subst={{{subst|}}}
}}
}}
{subst|}}}#if:{{{dpar4|}}}
|{subst|}}}emit category
|1={{{dpar4|}}}
|2={{{dkey4|}}}
|subst={{{subst|}}}
}}
}}
{subst|}}}#if:{{{dpar5|}}}
|{subst|}}}emit category
|1={{{dpar5|}}}
|2={{{dkey5|}}}
|subst={{{subst|}}}
}}
}}
{subst|}}}#if:{{{dpar6|}}}
|{subst|}}}emit category
|1={{{dpar6|}}}
|2={{{dkey6|}}}
|subst={{{subst|}}}
}}
}}
}}
{subst|}}}#if:1
|
{subst|}}}#if:{{{epar1|}}}
|{subst|}}}emit category
|1={{{epar1|}}}
|2={{{ekey1|}}}
|subst={{{subst|}}}
}}
}}
{subst|}}}#if:{{{epar2|}}}
|{subst|}}}emit category
|1={{{epar2|}}}
|2={{{ekey2|}}}
|subst={{{subst|}}}
}}
}}
{subst|}}}#if:{{{epar3|}}}
|{subst|}}}emit category
|1={{{epar3|}}}
|2={{{ekey3|}}}
|subst={{{subst|}}}
}}
}}
{subst|}}}#if:{{{epar4|}}}
|{subst|}}}emit category
|1={{{epar4|}}}
|2={{{ekey4|}}}
|subst={{{subst|}}}
}}
}}
{subst|}}}#if:{{{epar5|}}}
|{subst|}}}emit category
|1={{{epar5|}}}
|2={{{ekey5|}}}
|subst={{{subst|}}}
}}
}}
{subst|}}}#if:{{{epar6|}}}
|{subst|}}}emit category
|1={{{epar6|}}}
|2={{{ekey6|}}}
|subst={{{subst|}}}
}}
}}
}}
}}
}}
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
