[Bug 7062] Auto-merge multiple edits of an article by the same user within a specific time
https://bugzilla.wikimedia.org/show_bug.cgi?id=7062 Aaron Schulz jschulz_4...@msn.com changed: What|Removed |Added CC||jschulz_4...@msn.com Status|REOPENED|RESOLVED Resolution||WONTFIX --- Comment #7 from Aaron Schulz jschulz_4...@msn.com 2008-12-21 08:26:40 UTC --- Closing per serious issues in #1 and #2. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16706] Search engine hangs for certain keywords
https://bugzilla.wikimedia.org/show_bug.cgi?id=16706 --- Comment #7 from Niklas Laxström niklas.laxst...@gmail.com 2008-12-21 09:54:54 UTC --- Still doesn't work for me, but français moderne and parlée works, for example. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16706] Search engine hangs for certain keywords
https://bugzilla.wikimedia.org/show_bug.cgi?id=16706 Melancholie wiki.melancho...@web.de changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #8 from Melancholie wiki.melancho...@web.de 2008-12-21 10:18:31 UTC --- REOPEN-ing Still get blank pages and server errors: PHP fatal error in /usr/local/apache/common-local/php-1.5/extensions/MWSearch/MWSearch_body.php line 252: Call to a member function getNamespace() on a non-object -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16734] #ca-stable and #ca-current tab shown on rollback destination page, although there wasn't any unsighted revision
https://bugzilla.wikimedia.org/show_bug.cgi?id=16734 --- Comment #2 from Melancholie wiki.melancho...@web.de 2008-12-21 10:22:17 UTC --- No, then it's ok. Thus, I marked this bug as 'trivial'. So, only applies for the resulting rollback message page (once). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16706] Search engine hangs for certain keywords
https://bugzilla.wikimedia.org/show_bug.cgi?id=16706 --- Comment #9 from Rémi Kaupp le.korri...@gmail.com 2008-12-21 10:36:09 UTC --- Oh yep indeed for me too at the moment (Firefox 3.0.4 and IE 7 on Windows Vista 32bit). * cinéma gives a blank page. * français moderne works, but français doesn't. * Queries which only hit frwiki (not sister projects) seem to work fine as far as I've tested. * After some more testing, searches which return results only from the Wiktionary (vraquier), Wikiquote (bienvenue), Wikisource (français moderne), Wikinews (émeutes) and Wikibooks (tarte) all work. However so far I haven't been able to make the search work with keywords when I'm sure to get results from Wikiversity (I have tried most of the main articles names on Wikiversity's main page). I get either blank pages or the PHP error mentioned above. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16278] FlaggedRevisions extension: API sighting of revisions
https://bugzilla.wikimedia.org/show_bug.cgi?id=16278 P.Copp paul.copper...@googlemail.com changed: What|Removed |Added Attachment #5603 is|0 |1 obsolete|| --- Comment #11 from P.Copp paul.copper...@googlemail.com 2008-12-21 10:50:26 UTC --- Created an attachment (id=5604) -- (https://bugzilla.wikimedia.org/attachment.cgi?id=5604) Another fix: Only try parser cache, when reviewing the current revision of a page -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16489] Add diff to last sighted version to recent changes
https://bugzilla.wikimedia.org/show_bug.cgi?id=16489 --- Comment #10 from P. Birken pbir...@gmail.com 2008-12-21 11:08:43 UTC --- This is a general problem not specific to the recent changes link. However, I don't consider it serious, as for scenario 2, it is the job of the editor to make sure that this doesn't happen and flagged revisions help with finding this kind of edits in the first place. In fact, I often find edits of the kind scenario 2 and it was never a problem. As for scenario 1, it doesn't happen often and if it does, there are other ways of remedying this. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16739] New: Changing default image thumbnail size on Swedish Wikipedia
https://bugzilla.wikimedia.org/show_bug.cgi?id=16739 Summary: Changing default image thumbnail size on Swedish Wikipedia Product: MediaWiki Version: 1.14-svn Platform: All URL: http://sv.wikipedia.org/wiki/Wikipedia:Bybrunnen#Bildsto rlek OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: User preferences AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: jobj...@gmail.com Hello o mighty developers! On the Swedish Wikipedia, we have recently discussed the default size for thumbnail images, which is currently set to 180px. As this is not very much in today's world, and especially the IT-friendly Swedish-speaking regions, people manually enforce a higher resolution (by the size attribute in the image wikicode). We would like to avoid this, and provide a richer experience for our not logged in readers, by raising the default value to 250px. We believe that this is done by adjusting $wgDefaultUserOptions['thumbsize'] to 4 instead of 2, but I suppose you know what you are doing. The relevant discussion can be found at http://sv.wikipedia.org/wiki/Wikipedia:Bybrunnen#Bildstorlek, and an earlier discussion on the same subject can be found at http://sv.wikipedia.org/wiki/Wikipedia:Bildfr%C3%A5gor#Standardstorlek_p.C3.A5_minibild_.28thumbnail.29. Cheers! // User:Plrk -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16733] nopreload doesn't work anymore, gets parsed and preloaded
https://bugzilla.wikimedia.org/show_bug.cgi?id=16733 --- Comment #2 from P.Copp paul.copper...@googlemail.com 2008-12-21 11:39:33 UTC --- Has this extension ever been installed on any WMF wiki? I couldn't find any clue for that. Or are you requesting that this extension should be installed on de.wiktionary? If so, you should probably clarify this. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16739] Changing default image thumbnail size on Swedish Wikipedia
https://bugzilla.wikimedia.org/show_bug.cgi?id=16739 barracu...@gmail.com changed: What|Removed |Added CC||barracu...@gmail.com Component|User preferences|Site requests Product|MediaWiki |Wikimedia Version|1.14-svn|unspecified -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16740] New: list ProtectedTitles with API
https://bugzilla.wikimedia.org/show_bug.cgi?id=16740 Summary: list ProtectedTitles with API Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: API AssignedTo: roan.katt...@home.nl ReportedBy: umherirrender_de...@web.de CC: bryan.tongm...@gmail.com, vasi...@gmail.com Please make [[Special:ProtectedTitles]] available with API. A possibility: Add create to param apprtype from list=allpages -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16732] Wrong image ordering
https://bugzilla.wikimedia.org/show_bug.cgi?id=16732 --- Comment #3 from Roan Kattouw roan.katt...@home.nl 2008-12-21 12:27:09 UTC --- (In reply to comment #2) (In reply to comment #1) If your program somehow messes up aicontinue values, such things could happen. It's called gaifrom ;) I'm reading it from gaifrom attribute of allimages Indeed, if the API somehow returned the namespace on the query-continue, that could explain the first jumping, but not the jump back. It doesn't return the namespace, because all images are in the same namespace (File:). Maybe unrelated, I suspect that some results are skipped due to the API providing malformed XML (bug 16106). If you're using XML, I guess that could be the problem. Have you tried using other formats? Instinctively, I'd say PHP serialized is best shielded from this kind of malformedness. The Auto-Image-Auto bug looks like some weird race condition or improper handling of parallel requests. There're no parallel requests. Closing as WORKSFORME (because, well, it does). Race conditions, small memory corruptions or load-balancing slaves crazyness are not too reproductible. I'd also like having a failing URL and I am aware it is insufficient for fixing but hopefully someone would have an idea or will find this when facing the same problem. While having a failing URL would be very nice, even a log excerpt showing that the API is doing *something* wrong (like sorting stuff wrongly, setting the wrong query-continue values or malformed XML messing stuff up) would be good enough for me. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16733] nopreload doesn't work anymore, gets parsed and preloaded
https://bugzilla.wikimedia.org/show_bug.cgi?id=16733 --- Comment #3 from Melancholie wiki.melancho...@web.de 2008-12-21 12:30:08 UTC --- Hmm, you seem to be right: [[wikt:de:Spezial:Version]]. But when preloading isn't done by this extension, how is it done? Is preloading a core feature? Example: http://de.wiktionary.org/w/index.php?action=editpreload=Vorlage:Formatvorlage_Englisch_(Substantiv)title=123 If preloading isn't depending [[mw:Extension:Preloader]], this bug should get a request for creating nopreload for core. The point is that there should be a nopreload tag (like noinclude) available. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16739] Changing default image thumbnail size on Swedish Wikipedia
https://bugzilla.wikimedia.org/show_bug.cgi?id=16739 Max Semenik maxsem.w...@gmail.com changed: What|Removed |Added Keywords||shell -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16733] Treat preloaded pages like substituted templates
https://bugzilla.wikimedia.org/show_bug.cgi?id=16733
P.Copp paul.copper...@googlemail.com changed:
What|Removed |Added
URL|http://www.mediawiki.org/wik|http://de.wiktionary.org/w/i
|i/Extension:Preloader |ndex.php?action=editpreload
||=Vorlage:Formatvorlage_Engli
||sch_(Substantiv)title=123
Component|Preloader |Page editing
Product|MediaWiki extensions|MediaWiki
Summary|nopreload doesn't work|Treat preloaded pages like
|anymore, gets parsed and|substituted templates
|preloaded |
Version|any |1.14-svn
--- Comment #4 from P.Copp paul.copper...@googlemail.com 2008-12-21 12:45:47
UTC ---
(In reply to comment #3)
Hmm, you seem to be right: [[wikt:de:Spezial:Version]].
But when preloading isn't done by this extension, how is it done?
Is preloading a core feature?
Yes, at least if you mean preloading by adding the preload= or preloadtitle=
parameter to index.php. See [[mw:Manual:Parameters to index.php]]
If preloading isn't depending [[mw:Extension:Preloader]], this bug should get
a
request for creating nopreload for core.
The point is that there should be a nopreload tag (like noinclude)
available.
IMHO the page should be loaded as if it was transcluded with {{subst:}}, i.e.
instead of nopreload you could simply use noinclude. Changed the component
and summary accordingly.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16733] Treat preloaded pages like substituted templates
https://bugzilla.wikimedia.org/show_bug.cgi?id=16733 --- Comment #5 from Melancholie wiki.melancho...@web.de 2008-12-21 12:50:04 UTC --- Hmm, not sure whether people don't want to preload noinclude sections as well, sometimes. Otherwise this bug would be a duplicate of bug 5210 now, see comment #2. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16740] list ProtectedTitles with API
https://bugzilla.wikimedia.org/show_bug.cgi?id=16740 Roan Kattouw roan.katt...@home.nl changed: What|Removed |Added CC||roan.katt...@home.nl --- Comment #1 from Roan Kattouw roan.katt...@home.nl 2008-12-21 12:50:10 UTC --- (In reply to comment #0) Please make [[Special:ProtectedTitles]] available with API. A possibility: Add create to param apprtype from list=allpages That won't work, since create-protected pages usually don't exist. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16733] Treat preloaded pages like substituted templates
https://bugzilla.wikimedia.org/show_bug.cgi?id=16733 --- Comment #6 from Melancholie wiki.melancho...@web.de 2008-12-21 12:53:49 UTC --- ... comment #1 ;-) -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16733] Treat preloaded pages like substituted templates
https://bugzilla.wikimedia.org/show_bug.cgi?id=16733 --- Comment #7 from Melancholie wiki.melancho...@web.de 2008-12-21 12:57:51 UTC --- Ah, no I remember, this actually is an issue of http://mediawiki.org/wiki/Extension:InputBox on Wikimedia wikis, of course ;-) -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16706] Search engine hangs for certain keywords
https://bugzilla.wikimedia.org/show_bug.cgi?id=16706 --- Comment #11 from Robert Stojnic rain...@eunet.yu 2008-12-21 12:58:35 UTC --- Thanks for testing! I've poked around a bit but couldn't find any obvious reason why it works for some, but not for others, and why it consistently fails (even on different urls) at one time but not a couple of hours later. For now I am going to disable interwiki hits for fr.wp until r44802 is synced. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16733] Treat preloaded pages like substituted templates
https://bugzilla.wikimedia.org/show_bug.cgi?id=16733 P.Copp paul.copper...@googlemail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #8 from P.Copp paul.copper...@googlemail.com 2008-12-21 12:58:38 UTC --- (In reply to comment #5) Hmm, not sure whether people don't want to preload noinclude sections as well, sometimes. This could still be done with noinclude/noinclude or something. Otherwise this bug would be a duplicate of bug 5210 now, see comment #2. Right. ;) *** This bug has been marked as a duplicate of bug 5210 *** -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 5210] preload parser should parse noinclude (as well as includeonly )
https://bugzilla.wikimedia.org/show_bug.cgi?id=5210 P.Copp paul.copper...@googlemail.com changed: What|Removed |Added CC||wiki.melancho...@web.de --- Comment #8 from P.Copp paul.copper...@googlemail.com 2008-12-21 12:58:38 UTC --- *** Bug 16733 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 5210] preload parser should parse noinclude (as well as includeonly )
https://bugzilla.wikimedia.org/show_bug.cgi?id=5210 Melancholie wiki.melancho...@web.de changed: What|Removed |Added URL|http://meta.wikimedia.org/wi|http://mediawiki.org/wiki/Ex |ki/Inputbox |tension:InputBox OS/Version|Linux |All -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 8997] Parser hook output block level corruption
https://bugzilla.wikimedia.org/show_bug.cgi?id=8997 Philipp Spitzer philipp.spit...@gmx.at changed: What|Removed |Added CC||philipp.spit...@gmx.at --- Comment #14 from Philipp Spitzer philipp.spit...@gmx.at 2008-12-21 15:49:59 UTC --- A note about the workaround (replace output with marker in the parser hook - back-replace by content in the ParserAfterTidy) as described in http://www.mediawiki.org/wiki/Manual:Tag_extensions#How_can_I_avoid_modification_of_my_extension.27s_HTML_output.3F causes the final content to be wrapped with p. This causes the final output to fail the HTML validation in case the parser hook produces output that is not allowed inside p, e.g. noscript or div. I did not find a way to prevent this. Maybe a parameter would be needed where a tag extension can tell Mediawiki whether it returns inline or block elements? (or have I overlooked something in the documentation?) Otherwise I cannot find a way how to prevent Mediawiki to place the output in ps? -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16743] New: Special: Whatlinkshere does not list transcluded template links
https://bugzilla.wikimedia.org/show_bug.cgi?id=16743
Summary: Special:Whatlinkshere does not list transcluded template
links
Product: MediaWiki
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: Normal
Component: Special pages
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: jerryopen...@aol.com
An example:
A user creates the article [[The Foo]], and it becomes so large that the
article becomes split up into several subarticles, including [[History of
Foo]], [[Modern Foo]], and [[Foo in Fiction]]. On each subarticle,
[[Template:Main]] is translcuded by adding the {{Main|The Foo}}, which
reproduces Main Article: [[The Foo|]].
Another editor recognizes that [[The Foo]] is not compliant with the manual of
style, in that it has a superfluous The in the page name, and he want to fix
this by moving the article to [[Foo]]. Prior to doing this, the diligent
editor checks [[Special:Whatlinkshere/The_Foo]], to determine if any links need
to be updated in the process, to prevent double-redirects. He is told No
pages in the English Wikipedia link to [[The Foo]], and proceeds with the page
move.
The result is several double-redirects which confuse some readers. In this
example, it was only three, and they would be easily found by reading the [[The
Foo]] page itself; there are certainly other cases where it is not so easy and
more prolific.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16744] New: CategoryTree: If called on non-existent category, exposes strip markers
https://bugzilla.wikimedia.org/show_bug.cgi?id=16744 Summary: CategoryTree: If called on non-existent category, exposes strip markers Product: MediaWiki extensions Version: any Platform: All URL: http://en.wikipedia.org/w/index.php?title=Wikipedia:Wiki Project_Climbingoldid=254590422 OS/Version: All Status: NEW Severity: normal Priority: Normal Component: CategoryTree AssignedTo: dan...@brightbyte.de ReportedBy: paul.copper...@googlemail.com When categorytreeFoo/categorytree is called on an non-existent category Foo, all strip markers before the tag are left stripped (see URL). Probably, there's a recursive call to the parser inside the extension which clears the parser state. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16744] CategoryTree: If called on non-existent category, exposes strip markers
https://bugzilla.wikimedia.org/show_bug.cgi?id=16744 --- Comment #1 from P.Copp paul.copper...@googlemail.com 2008-12-21 17:27:10 UTC --- Created an attachment (id=5605) -- (https://bugzilla.wikimedia.org/attachment.cgi?id=5605) proposed fix: wfMsgExt-wfMsgHtml -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 8249] Parser functions to obtain talk page, namespace, talk namespace, basename, etc. for named targets
https://bugzilla.wikimedia.org/show_bug.cgi?id=8249
Happy-melon happy_me...@hotmail.co.uk changed:
What|Removed |Added
CC||happy_me...@hotmail.co.uk
--- Comment #7 from Happy-melon happy_me...@hotmail.co.uk 2008-12-21
18:09:35 UTC ---
This should be implemented by allowing these variables to take one parameter,
the full title to evaluate on. The current implementation then becomes the
'fallback' case where there is no such value, a natural default. So
{{FULLPAGENAME:Foo}} would be transparent, and {{NAMESPACE:Help:Foo}} == Help.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16745] New: Ability to list user revisions on a spesific article
https://bugzilla.wikimedia.org/show_bug.cgi?id=16745 Summary: Ability to list user revisions on a spesific article Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: History/Diffs AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: wikipedia.kawaii.n...@gmail.com http://en.wikipedia.org/w/api.php?action=queryprop=revisionstitles=Main_Pagervlimit=500rvuser=MZMcBride You are looking at the HTML representation of the XML format. HTML is good for debugging, but probably is not suitable for your application. See complete documentation, or API help for more information. ?xml version=1.0? api query normalized n from=Main_Page to=Main Page / /normalized pages page pageid=15580374 ns=0 title=Main Page revisions rev revid=250138233 user=MZMcBride timestamp=2008-11-07T00:25:19Z comment=cleaned up code, per talk / rev revid=210742813 user=MZMcBride timestamp=2008-05-07T05:22:48Z comment=rv / rev revid=210742552 user=MZMcBride timestamp=2008-05-07T05:20:55Z comment=restored margin-top with lower value / rev revid=210742376 user=MZMcBride timestamp=2008-05-07T05:19:46Z comment=rm margin-top, see talk / rev revid=199549748 user=MZMcBride timestamp=2008-03-20T08:11:25Z comment=rv / rev revid=197643346 user=MZMcBride timestamp=2008-03-12T03:52:20Z comment=rm unneeded div / rev revid=191953558 user=MZMcBride timestamp=2008-02-16T23:45:51Z comment=bypassed redirect / /revisions /page /pages /query /api Above is an example use. I'd like a different page that lets me display user contribution (individual revisions) like page history. Basically I want *the diff link to be clickable *timestamp displayed in standard dating format (depending on users pref like how history date time is displayed) *possibly adding a text box to history pages so that I can search a users contribution. **For example if I went to page history of Main Page and search for MZMcBride I'd get the above feed -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16330] When nesting refs using cite.php extension, the ordering is wrong
https://bugzilla.wikimedia.org/show_bug.cgi?id=16330 Brad Jorsch b-jor...@northwestern.edu changed: What|Removed |Added CC||b-jor...@northwestern.edu --- Comment #2 from Brad Jorsch b-jor...@northwestern.edu 2008-12-21 19:12:34 UTC --- (In reply to comment #1) I can't see any advantage to allowing nested refs at all. Why would you want to cite a citation? :D You might want to cite a footnote. It seems part of the problem with allowing reffoorefbar/ref/ref is that the parser interprets it as one node reffoorefbar/ref instead of as two nested refs; see http://en.wikipedia.org/w/api.php?action=queryformat=yamlfmaction=expandtemplatestext=%3Cref%3Efoo%3Cref%3Ebar%3C/ref%3E%3C/ref%3Egeneratexml=1 -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 323] Phase I usernames with underscores break the system.
https://bugzilla.wikimedia.org/show_bug.cgi?id=323 Aryeh Gregor simetrical+wikib...@gmail.com changed: What|Removed |Added CC||simetrical+wikib...@gmail.co ||m Keywords||shell --- Comment #5 from Aryeh Gregor simetrical+wikib...@gmail.com 2008-12-21 19:17:13 UTC --- These still haven't been cleaned up . . . for instance, user_id 87496 is Nicholas_Lativy. [[User:Nicholas Lativy]] is a different user, 90574. These should be identified and dealt with, although they're probably long abandoned. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16744] CategoryTree: If called on non-existent category, exposes strip markers
https://bugzilla.wikimedia.org/show_bug.cgi?id=16744 Roan Kattouw roan.katt...@home.nl changed: What|Removed |Added CC||roan.katt...@home.nl --- Comment #2 from Roan Kattouw roan.katt...@home.nl 2008-12-21 19:32:55 UTC --- Probably related to bug 16129, maybe even a duplicate. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16129] Transcluded Special:Newpages and Special: Newimages expose strip markers and desanitize html when returning zero results
https://bugzilla.wikimedia.org/show_bug.cgi?id=16129 --- Comment #7 from Roan Kattouw roan.katt...@home.nl 2008-12-21 19:33:12 UTC --- Bug 16744 may be related. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 10788] Filter page histories by user, or contributions by title
https://bugzilla.wikimedia.org/show_bug.cgi?id=10788 Roan Kattouw roan.katt...@home.nl changed: What|Removed |Added CC||roan.katt...@home.nl Keywords|schema-change | --- Comment #3 from Roan Kattouw roan.katt...@home.nl 2008-12-21 19:37:19 UTC --- (In reply to comment #1) I'm committing a schema change for this now. It will require a new index on the revision table, so it probably won't be live for quite some time even once the code to do it is written. Removing schema-change keyword on the assumption that it's already happened: the comment is from 2007 and the API manages to do this just fine (prop=revisionsrvuser=Catropetitles=Main_Page). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16744] CategoryTree: If called on non-existent category, exposes strip markers
https://bugzilla.wikimedia.org/show_bug.cgi?id=16744 --- Comment #3 from P.Copp paul.copper...@googlemail.com 2008-12-21 19:41:46 UTC --- (In reply to comment #2) Probably related to bug 16129, maybe even a duplicate. Somehow related, yes. The cause is in both cases calling $wgParser-parse recursively, which clears the parser state and thus loses strip marker info. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16129] Transcluded Special:Newpages and Special: Newimages expose strip markers and desanitize html when returning zero results
https://bugzilla.wikimedia.org/show_bug.cgi?id=16129
--- Comment #8 from P.Copp paul.copper...@googlemail.com 2008-12-21 19:58:20
UTC ---
(In reply to comment #5)
More testing:
This also affects {{Special:NewImages}} (such as on a wiktionary with no
images) the same. They have addWikiMsg() in common for zero results. It also
exposes strip markers for all tested parser extension tags that appear
*before*
the call (but not after?). Renaming bug to clarify.
Right. addWikiMsg() calls wfMsgExt() with option 'parse' so we have another
case of recursively calling $wgParser-parse() which should be avoided.
Fix could be to simply not output the message if the special page is included.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 8249] Parser functions to obtain talk page, namespace, talk namespace, basename, etc. for named targets
https://bugzilla.wikimedia.org/show_bug.cgi?id=8249 Brad Jorsch b-jor...@northwestern.edu changed: What|Removed |Added Keywords||patch -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 15814] Special: RevisionDelete should have clearer logs for individual revisions
https://bugzilla.wikimedia.org/show_bug.cgi?id=15814 --- Comment #2 from MZMcBride pub...@mzmcbride.com 2008-12-21 21:28:14 UTC --- Bumping bug (not supposed to do that, yeah, yeah), but it's two months yesterday since the previous comment was made. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16748] New: Null revisions are stored in the database with rev_len= null
https://bugzilla.wikimedia.org/show_bug.cgi?id=16748
Summary: Null revisions are stored in the database with
rev_len=null
Product: MediaWiki
Version: 1.14-svn
Platform: All
URL: http://de.wikipedia.org/w/index.php?title=Diskussion:J%C
3%BCrgen_Els%C3%A4sseroldid=54408336
OS/Version: All
Status: NEW
Severity: normal
Priority: Normal
Component: Page editing
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: paul.copper...@googlemail.com
Currently, null revisions created by page protections or moves are stored
without specifying a value for the rev_len field, thus it is stored as NULL.
This causes weird bugs like the one shown in the URL above, where the
{{PAGESIZE}} parser function don't work correctly.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16748] Null revisions are stored in the database with rev_len=null
https://bugzilla.wikimedia.org/show_bug.cgi?id=16748 --- Comment #1 from P.Copp paul.copper...@googlemail.com 2008-12-21 21:44:08 UTC --- Created an attachment (id=5607) -- (https://bugzilla.wikimedia.org/attachment.cgi?id=5607) Proposed fix: add rev_len field to Revision::newNullEdit() -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16748] Null revisions are stored in the database with rev_len=null
https://bugzilla.wikimedia.org/show_bug.cgi?id=16748 Raimond Spekking raimond.spekk...@gmail.com changed: What|Removed |Added Keywords||need-review, patch -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16748] Null revisions are stored in the database with rev_len=null
https://bugzilla.wikimedia.org/show_bug.cgi?id=16748 P.Copp paul.copper...@googlemail.com changed: What|Removed |Added URL|http://de.wikipedia.org/w/in|http://de.wikipedia.org/wiki |dex.php?title=Diskussion:J%C|/Benutzer:P.Copp/temp/Bug167 |3%BCrgen_Els%C3%A4sseroldid|48 |=54408336 | -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16743] Special:Whatlinkshere does not list transcluded template links
https://bugzilla.wikimedia.org/show_bug.cgi?id=16743 Roan Kattouw roan.katt...@home.nl changed: What|Removed |Added CC||roan.katt...@home.nl Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Roan Kattouw roan.katt...@home.nl 2008-12-21 22:41:24 UTC --- This works for me locally, using a copy of [[Template:Main]] from enwiki. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16748] Null revisions are stored in the database with rev_len=null
https://bugzilla.wikimedia.org/show_bug.cgi?id=16748 Roan Kattouw roan.katt...@home.nl changed: What|Removed |Added CC||roan.katt...@home.nl Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Roan Kattouw roan.katt...@home.nl 2008-12-21 22:36:11 UTC --- Patch committed in r44885. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16750] New: class='mw-imagepage-duplicates' contains old image-links
https://bugzilla.wikimedia.org/show_bug.cgi?id=16750 Summary: class='mw-imagepage-duplicates' contains old image-links Product: MediaWiki Version: 1.14-svn Platform: All URL: http://de.wikipedia.org/wiki/Datei:KormoranD.jpg OS/Version: All Status: NEW Keywords: easy Severity: minor Priority: Normal Component: Images AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: schwalbe.wikipe...@gmx.de Links to Commons Files in section class='mw-imagepage-duplicates' should start with 'http://commons.wikimedia.org/wiki/File:' instead of 'http://commons.wikimedia.org/wiki/Image:' in order to allow for correct script reading of this section. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16697] Unicode combining characters are difficult to edit in some browsers
https://bugzilla.wikimedia.org/show_bug.cgi?id=16697 --- Comment #17 from Andrew Cunningham lang.supp...@gmail.com 2008-12-21 23:49:42 UTC --- (In reply to comment #12) The MediaWiki default is not to specify fonts at all for any language. Which is actually a good approach, stylesheets should be language neutral as much as possible. But there are two scenarios for content: 1) all content in a single page is monolingual - in which case all is fine 2) content is predominately in one language, but contains words, phrases, quotes from other languages - this is a more problematic scenario. Since it would require different fonts to be used to display different languages. IN most the major languages that have full OS support current approach works fine. OS font-linking/switching and browser based approaches work fine. But for lesser used languages where there is no official OS support, things become more problematic, since different fonts may need to be specified for that language as distinct form the text of the surrounding page. The easiest and simplest approach is the use of language tagging in the markup and then users can tie their own css rules to the language markup. Essentially the nature of Wikipedia content, means that the first fall back is OS and web browser fallback mechanisms, the second fall back is end user CSS overrides. For monolingual content in a language specific wiki, its possible to have some sensible CSS rules in a language specific customisations to monobook.css For content that includes words and phrases in other languages, the most sensible approach is language markup, this allows CSS rules to be created for wiki specific monobook.css or user specific CSS rules. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16697] Unicode combining characters are difficult to edit in some browsers
https://bugzilla.wikimedia.org/show_bug.cgi?id=16697 --- Comment #18 from Andrew Cunningham lang.supp...@gmail.com 2008-12-22 00:01:54 UTC --- (In reply to comment #13) A solution should not be confined to the ln.wikipedia. It should also work on Commons or Meta. When CSS rules are supposed to be language specific, then the support of the CSS should be based on what language is selected in the user preferences. But a user may have their preferences set to one language and may also work in other languages. So that approach will work in many cases but not in all. MediaWiki is software that should work for any language. It does only need to specify fonts that work. It does work for any language. But for languages not supported officially by major OS vendors, things have always been more problematic, the advent of Unicode doesn't change that. There are limitations to web browsers, operating system support, and even HTML and CSS specifications. In an ideal world there would be comprehensive Latin script OpenType fonts available by default within an OS. But even is there are, web browsers and CSS provide no way to control which OpenType features are used for specific HTML documents. So its impossible to use a single Latin script font for all Latin script languages, even if it has language specific features and alternative glyphs for various languages. Browsers and CSS provide no way to access or control these features. The best approach I've found for working with multiple scripts and languages (and some projects i've worked with up to 100 languages) is to have the main CSS rules be language neutral, tag primary language of a document, allow mechanisms for authors to indicate/markup up change of languages, allow language specific styling independent of the main styling for the theme/skin, and allow users to override/control aspects of the language specific styling. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16751] New: Support multiple file uploads via Special:Upload (backend/ infrastructure)
https://bugzilla.wikimedia.org/show_bug.cgi?id=16751 Summary: Support multiple file uploads via Special:Upload (backend/infrastructure) Product: MediaWiki Version: unspecified Platform: All URL: http://commons.wikimedia.org/wiki/Special:Upload OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: Uploading AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: br...@wikimedia.org As long discussed, many folks would benefit from being able to upload multiple files at once, such as when uploading a bunch of photos from an event. We need the backend infrastructure for accepting multiple files in one submission, and some front-end UI for sensibly handling the name/description/licensing info for each file. Separate bugs will cover specific UI implementations for the actual file selection, which is another fun thing. :) -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16751] Support multiple file uploads via Special:Upload (backend/ infrastructure)
https://bugzilla.wikimedia.org/show_bug.cgi?id=16751 Brion Vibber br...@wikimedia.org changed: What|Removed |Added Blocks||16752 -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16753] New: Support Flash-based upload widget to handle multiple file selection
https://bugzilla.wikimedia.org/show_bug.cgi?id=16753 Summary: Support Flash-based upload widget to handle multiple file selection Product: MediaWiki Version: unspecified Platform: All URL: http://commons.wikimedia.org/wiki/Special:Upload OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: Uploading AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: br...@wikimedia.org Blocks: 16751 Standard HTML 4 / XHTML 1 file upload widget only allows you to select one file at a time, which is terrible. Flash upload widgets can provide multiple-file selection, as well as some other nice things like progress feedback. Compare with WordPress's Flash upload widget; see if it's compatible and could be adapted directly? (No patent-encumbered codec issues are involved, so this falls under our acceptable use cases for Flash. Flash's wide install base, and not requireing the user to click through a full-system-access permissions dialog to do file uploads, make it more attractive for this purpose than Java.) When Flash isn't available, should naturally fall back to the standard upload widget. (It should also be possible to select the standard upload widget manually, in case of difficulties with the particular version.) Requires actual backend support for dealing with multiple file uploads -- bug 16751. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16751] Support multiple file uploads via Special:Upload (backend/ infrastructure)
https://bugzilla.wikimedia.org/show_bug.cgi?id=16751 Brion Vibber br...@wikimedia.org changed: What|Removed |Added Depends on||16753 -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16743] Special:Whatlinkshere does not list transcluded template links
https://bugzilla.wikimedia.org/show_bug.cgi?id=16743 Jerry Lavoie jerryopen...@aol.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #2 from Jerry Lavoie jerryopen...@aol.com 2008-12-22 01:30:20 UTC --- It does not work on enwiki. But you can keep this bugzilla request closed, as I am now persuing a bot to perform this check, and have expanded the scope to include checking for links to disambiguation pages, and redlinks. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 477] Accesskeys conflict with browser keyboard shortcuts
https://bugzilla.wikimedia.org/show_bug.cgi?id=477 Brion Vibber br...@wikimedia.org changed: What|Removed |Added CC||br...@wikimedia.org --- Comment #54 from Brion Vibber br...@wikimedia.org 2008-12-22 01:31:12 UTC --- WebKit (Safari) on Mac is apparently switching from Control to Control+Option to avoid the conflict with Emacs keybindings... unless VoiceOver is enabled, in which case Control+Option conflicts, so it will then use Control! http://trac.webkit.org/changeset/38211 Hurrah for predictability. :P -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16751] Support multiple file uploads via Special:Upload (backend/ infrastructure)
https://bugzilla.wikimedia.org/show_bug.cgi?id=16751 --- Comment #1 from Aiuw niu.us...@gmail.com 2008-12-22 01:48:33 UTC --- (In reply to comment #0) As long discussed, many folks would benefit from being able to upload multiple files at once, such as when uploading a bunch of photos from an event. We need the backend infrastructure for accepting multiple files in one submission, and some front-end UI for sensibly handling the name/description/licensing info for each file. Separate bugs will cover specific UI implementations for the actual file selection, which is another fun thing. :) Have you seen http://www.mediawiki.org/wiki/Extension:MultiUpload ? -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
