Re: [Wikitech-l] Any accepted use cases that block bug 1310?
Robert Rohde wrote: > Actually, if one is following the HTML4 spec then would be > expected to nest. (Not particularly useful as far as I can see, but > it is what it is.) in wikitext is explicitly not the same as in HTML. Unlike in HTML, HTML-like tags which appear inside are considered to be literal and are escaped. This behaviour is often used. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Any accepted use cases that block bug 1310?
On Sun, Sep 20, 2009 at 8:14 PM, Tim Starling wrote: > Robert Rohde wrote: >> I am looking at bug 1310, which involves parser behavior such that >> when given nested tag extensions, i.e.: >> >> >> AAA >> BBB >> CCC >> >> >> The parser selects the tag block as running from the first open tag to >> the FIRST close tag, i.e. in the example it gives: >> >> AAA >> BBB >> >> as the inner text of the first tag. It should be fairly >> straightforward to modify this to handle nested tags by checking for >> additional open tags in the inner string. > > This syntax was chosen because originally and were the > only such tags (I called them xmlish elements in [[mw:Preprocessor > ABNF]]). Those two tags were imagined as being useful solely for > escaping HTML and other wikitext, so that it is displayed literally on > the page. No nesting behaviour was desirable. Actually, if one is following the HTML4 spec then would be expected to nest. (Not particularly useful as far as I can see, but it is what it is.) I could see arguments in either direction for nowiki. For example, it might be nice to be able to wrap around arbitrary blocks without worrying if another nowiki was already present in the middle. > , and then the extension interface, were added afterwards using > the same syntax. There is no application for nesting with since > the contents are TeX. > > was the first tag to assume that its contents were some kind of > wikitext, unfortunately this was an inefficient and ugly hack on the > software side, and could have been much more easily done, with > appropriate nesting behaviour, if a different syntax had been chosen. > Other tags were later added, following this bad example. > > So if you ask me if there's a use case, I would say most likely yes, > especially for and , and very likely for the extensions > that shell out, like and . These use cases would > become especially obvious if an extension registered a short name name > like <->, then the lack of a syntax for communicating this string with > a shell command would become especially obvious. I can't really think of an example where it would be valid and useful to enclose a single tag, i.e. x + 5 = 6 is silly, but I can't rule out that there might be some circumstance somewhere where one would want that behavior. > But it would be possible to enable or disable nesting on a per-tag > basis at registration time. That seems like probably the best option. -Robert Rohde ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Any accepted use cases that block bug 1310?
Robert Rohde wrote: > I am looking at bug 1310, which involves parser behavior such that > when given nested tag extensions, i.e.: > > > AAA > BBB > CCC > > > The parser selects the tag block as running from the first open tag to > the FIRST close tag, i.e. in the example it gives: > > AAA > BBB > > as the inner text of the first tag. It should be fairly > straightforward to modify this to handle nested tags by checking for > additional open tags in the inner string. This syntax was chosen because originally and were the only such tags (I called them xmlish elements in [[mw:Preprocessor ABNF]]). Those two tags were imagined as being useful solely for escaping HTML and other wikitext, so that it is displayed literally on the page. No nesting behaviour was desirable. , and then the extension interface, were added afterwards using the same syntax. There is no application for nesting with since the contents are TeX. was the first tag to assume that its contents were some kind of wikitext, unfortunately this was an inefficient and ugly hack on the software side, and could have been much more easily done, with appropriate nesting behaviour, if a different syntax had been chosen. Other tags were later added, following this bad example. So if you ask me if there's a use case, I would say most likely yes, especially for and , and very likely for the extensions that shell out, like and . These use cases would become especially obvious if an extension registered a short name name like <->, then the lack of a syntax for communicating this string with a shell command would become especially obvious. But it would be possible to enable or disable nesting on a per-tag basis at registration time. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Bugzilla Weekly Report
MediaWiki Bugzilla Report for September 14, 2009 - September 21, 2009 Status changes this week Bugs NEW : 136 Bugs ASSIGNED : 11 Bugs REOPENED : 17 Bugs RESOLVED : 98 Total bugs still open: 3893 Resolutions for the week: Bugs marked FIXED : 68 Bugs marked REMIND : 0 Bugs marked INVALID: 8 Bugs marked DUPLICATE : 23 Bugs marked WONTFIX: 6 Bugs marked WORKSFORME : 4 Bugs marked LATER : 1 Bugs marked MOVED : 0 Specific Product/Component Resolutions & User Metrics New Bugs Per Component Site requests 6 Categories 6 LiquidThreads 5 General/Unknown 5 Vector Skin 3 New Bugs Per Product MediaWiki 27 Wikimedia 12 MediaWiki extensions22 Wikipedia Mobile1 Top 5 Bug Resolvers roan.kattouw [AT] gmail.com 17 agarrett [AT] wikimedia.org 15 JSchulz_4587 [AT] msn.com 11 innocentkiller [AT] gmail.com 9 alex.emsenhuber [AT] bluewin.ch 6 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Any accepted use cases that block bug 1310?
2009/9/20 Petr Kadlec : > “There’s no way”? Well, obviously, there is always a way do it > differently… But nested refs can be useful especially with grouped > references [1], when a footnote can refer to a source (or, more > generally, refs from one group can refer to another group). Ah, that makes sense :-) I keep thinking of references as just a reference, not as the extended footnotes many people use. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Any accepted use cases that block bug 1310?
On Sun, Sep 20, 2009 at 10:04 AM, David Gerard wrote: > 2009/9/20 Robert Rohde : > >> However, since this is parser behavior going back to the dawn of time >> (first reported in MW 1.4), I wanted to ask if there are known use >> cases where the current behavior is actually the expected behavior? >> In other words, are there any use cases in the current code base or >> extensions that would necessarily break if the parser were changed to >> allow nested tags? I can't think of any right now, but I wouldn't >> want to modify an old parser quirk without giving it a good look. For >> the record, my particular interest is related to nested refs. > > > What's the actual use case for nested refs? (Do you have an example > page or two where they're useful and there's no way to do it right > without nesting the refs?) There is a workaround (of sorts) using #tag which has been recommended for nesting refs on enwiki for two years [1]. So, nested refs will exist in the wild in some fashion whether we like them or not. I'd like to fully support nested refs IF it isn't going to break other things. If it is likely to be a major mess to change this piece of the parser, then I wouldn't try. The most common use case seems to be when someone wants to have a note on a reference or a reference on a note (where each is broken up into different sections using ref's group attribute). It is still very rare to use ref nesting though. Some examples are at [2][3][4]. -Robert Rohde [1] http://en.wikipedia.org/wiki/Wikipedia:Footnotes#Known_bugs [2] http://en.wikipedia.org/wiki/Super_Nintendo_Entertainment_System#Content_notes [3] http://en.wikipedia.org/wiki/Battle_of_Barnet#Footnotes [4] http://en.wikipedia.org/wiki/List_of_Governors_of_California#Notes ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Any accepted use cases that block bug 1310?
2009/9/20 David Gerard : > What's the actual use case for nested refs? (Do you have an example > page or two where they're useful and there's no way to do it right > without nesting the refs?) “There’s no way”? Well, obviously, there is always a way do it differently… But nested refs can be useful especially with grouped references [1], when a footnote can refer to a source (or, more generally, refs from one group can refer to another group). Note that there is a workaround for this problem, explained at the enwp help page. [2] -- [[cs:User:Mormegil | Petr Kadlec]] [1] http://www.mediawiki.org/wiki/Extension:Cite/Cite.php#Grouped_references [2] http://en.wikipedia.org/wiki/Wikipedia:Footnotes#Known_bugs ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Any accepted use cases that block bug 1310?
2009/9/20 Robert Rohde : > However, since this is parser behavior going back to the dawn of time > (first reported in MW 1.4), I wanted to ask if there are known use > cases where the current behavior is actually the expected behavior? > In other words, are there any use cases in the current code base or > extensions that would necessarily break if the parser were changed to > allow nested tags? I can't think of any right now, but I wouldn't > want to modify an old parser quirk without giving it a good look. For > the record, my particular interest is related to nested refs. What's the actual use case for nested refs? (Do you have an example page or two where they're useful and there's no way to do it right without nesting the refs?) - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Any accepted use cases that block bug 1310?
I am looking at bug 1310, which involves parser behavior such that when given nested tag extensions, i.e.: AAA BBB CCC The parser selects the tag block as running from the first open tag to the FIRST close tag, i.e. in the example it gives: AAA BBB as the inner text of the first tag. It should be fairly straightforward to modify this to handle nested tags by checking for additional open tags in the inner string. However, since this is parser behavior going back to the dawn of time (first reported in MW 1.4), I wanted to ask if there are known use cases where the current behavior is actually the expected behavior? In other words, are there any use cases in the current code base or extensions that would necessarily break if the parser were changed to allow nested tags? I can't think of any right now, but I wouldn't want to modify an old parser quirk without giving it a good look. For the record, my particular interest is related to nested refs. -Robert Rohde ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Toolserver-l] Archive of visitor stats
2009/9/18 Erik Zachte : > I think it is extremely important to keep these files for later analysis by > historians and others. > > Mathias Schindler also keep an archive or at least did till April (Berlin > conference). > He even bought a dedicated external drive for it. Right now, I have a single copy of all the files from December 2007 to April 2009 on a single hard drive. I haven't done any integrity checks beyond some initial tests. The dataset has some missing spots when the service to produce the files was not working. In some cases, it is just an empty .gz file, in some cases there was no file produced at all. In my spare time, I will try to load the files from May to now to this hard drive until it is full. The situation is rather uncomfortable for me since I am in no way able to guarantee the integrity and safety of these files for a longer time frame. While I might continue downloading and "storing" the files, I would be extremely happy to hear that the full and unabridged set of files is available a) to anyone b) for an indefinite time span c) free of charge d) with some backup and data integrity check in place. Speaking of wish lists, a web-accessible service to work with the data would be nice. We know for sure that journalists and hopefully some more demographics like the data, numbers and resulting shiny graphs. Mathias ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Software updates Wednesday morning
It is happening on WinXP, FF 3.5.1, 3.5.2, 3.5.3, on "clean" setup as well.
It is apparently specific to Windows (not surprising), and is some
side effect of the ABBR element; using lots and lots on a page causes
endless or nearly endless CPU.
Attempting to turn it off with "abbr { display:none; }" makes it
worse: it is then 100% CPU instead of 95-97%. FF renders the page,
then goes back and re-renders the first occurrence of each ABBR
element with a superscript giving the expansion. I suspect it is doing
this (re-render) for all of the elements on the page, so with more
than a few it goes CPU bound for a long time. But also in some way
worse than that, since it doesn't stop. (quadratic with number of the
elements? ;-)
Makes RC and watchlist unusable for now.
(mozilla seems to be susceptible to going CPU bound and thrashing VM
under various odd conditions, almost always on Windoze ;-)
Best,
Robert
On Thu, Sep 17, 2009 at 11:20 PM, Platonides wrote:
> Robert Ullmann wrote:
>> Hi,
>>
>> Something bad happened, having to do with the "legend" junk add to RC
>> and similar pages. Firefox will go compute bound (or very nearly) as
>> long as the page is open, even if hours.
>>
>> It isn't java/javascript (first suspect ;-), turning them off has no
>> effect. It doesn't quite happen with 50 changes shown, always happens
>> with 100 or more. Long pages without the cruft (eg.
>> http://en.wiktionary.org/wiki/Special:Contributions/93.152.180.56 )
>> don't cause the problem.
>>
>> WinXP updated to current, FF at 3.5.1 and 3.5.2.
>>
>> Is there a way to turn that added stuff off? It is pure noise, not
>> helpful at all. (yes, css display:none, but must everyone do that?)
>>
>> best,
>> Robert
>
>
> Can't reproduce. Where *is* it happening?
> http://en.wiktionary.org/wiki/Special:RecentChanges ?
>
>
> ___
> 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
