[Bug 29928] show translated titles per user language
https://bugzilla.wikimedia.org/show_bug.cgi?id=29928 Niklas Laxström changed: What|Removed |Added Depends on||29975 -- 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 491] Categories need piping feature to list by alternative name
https://bugzilla.wikimedia.org/show_bug.cgi?id=491 Niklas Laxström changed: What|Removed |Added Depends on||29975 -- 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 29975] New: Provide a way to alter page titles in category listings
https://bugzilla.wikimedia.org/show_bug.cgi?id=29975 Web browser: --- Bug #: 29975 Summary: Provide a way to alter page titles in category listings Product: MediaWiki Version: 1.19-svn Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: Categories AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: niklas.laxst...@gmail.com Blocks: 491, 29928 Classification: Unclassified There should be a way to not use the actual page titles but something else instead in the category listing. Would be useful for example translated titles. -- 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 13151] Transfer some Features from DPL to
https://bugzilla.wikimedia.org/show_bug.cgi?id=13151 fastgoldf...@gmail.com changed: What|Removed |Added CC||fastgoldf...@gmail.com --- Comment #6 from fastgoldf...@gmail.com 2011-07-20 06:40:06 UTC --- Here's some more ideas: http://smw.referata.com/wiki/Add_page_metadata_properties_to_a_page_(using_DPL) Having access to page metadata via SMW opens up very exciting possibilities. Part of the struggle with creating a useful semantic wiki is in managing the data. Being able to examine a wiki semantically would be a very power tool for finding out what's in your wiki (and what might be missing). Just today, the thought crossed my mind that I would like to be able to find out what templates are being used on pages with certain properties. That would make it easy for me to reduce complexity by reducing the number of templates I'm using. There's really an enormous amount of power and flexibility that can be offered with semantic metadata. I look forward to seeing these features. -- 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 29693] Resource Loader loads CSS multiple times
https://bugzilla.wikimedia.org/show_bug.cgi?id=29693
Michael Plasmeier (ThePlaz) changed:
What|Removed |Added
CC||p...@theplaz.com
--- Comment #7 from Michael Plasmeier (ThePlaz) 2011-07-20
04:53:22 UTC ---
I had the same issue on my heavily customized wiki with my custom skin.
(http://theplaz.com)
I hacked a fix by commenting out the loop in OutputPage::buildCssLinks
//foreach ( array( 'site', 'private', 'user' ) as $group ) {
$ret .= $this->makeResourceLoaderLink($sk, array_merge( $styles['site'],
$styles['user'] ), 'styles');
//}
The sites and users scripts are all loaded at once, so commenting out the
foreach does not remove functionality.
--
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 29974] New: Optional thumb sized zim image export
https://bugzilla.wikimedia.org/show_bug.cgi?id=29974 Web browser: --- Bug #: 29974 Summary: Optional thumb sized zim image export Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: Collection AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: tf...@wikimedia.org CC: developm...@pediapress.com Classification: Unclassified I can't verify right now as openZim export is down but as of last export I noticed that we export full sized images into a collection even though we only surface the thumb sized image. It would be better if you could pick wether you want full sized images or not. (e.g. print) -- 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 29973] New: Render server error on zim output
https://bugzilla.wikimedia.org/show_bug.cgi?id=29973
Web browser: ---
Bug #: 29973
Summary: Render server error on zim output
Product: MediaWiki extensions
Version: any
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: Collection
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: tf...@wikimedia.org
CC: developm...@pediapress.com
Classification: Unclassified
When trying to generate the zim file for
http://en.wikipedia.org/wiki/Book:Nobel_Peace_Prize i get the following.
An error occured on the render server: RuntimeError: command failed with
returncode 256: ['mw-render', '-w', 'zim', '-c',
'cache/f3/f39a5cb74094ca71/collection.zip', '-o',
'cache/f3/f39a5cb74094ca71/output.zim', '--status',
'qserve://localhost:14311/f39a5cb74094ca71:render-zim', '--template-blacklist',
'MediaWiki:PDF Template Blacklist', '--template-exclusion-category', 'Exclude
in print', '--print-template-prefix', 'Print', '--print-template-pattern',
'$1/Print', '--language', 'en'] Last Output: 2011-07-20T04:27:31
mwlib.options.warn >> Both --print-template-pattern and --print-template-prefix
(deprecated) specified. Using --print-template-pattern only. 1% reading
/tmp/tmpHhjGCz/revisions-1.txt 0% generating zimfile STARTING image not found
http://bits.wikimedia.org/skins-1.17/common/images/magnify-clip.png
/home/pp/local/lib/python2.6/urllib.py:1222: UnicodeWarning: Unicode equal
comparison failed to convert both arguments to Unicode - interpreting them as
being unequal res = map(safe_map.__getitem__, s) 0% error removing
'/tmp/tmpHhjGCz' Traceback (most recent call last): File
"/home/pp/local/bin/mw-render", line 9, in
load_entry_point('mwlib==0.12.14', 'console_scripts', 'mw-render')() File
"/home/pp/local/lib/python2.6/site-packages/mwlib-0.12.14-py2.6-linux-x86_64.egg/mwlib/apps/render.py",
line 214, in main return Main()() File
"/home/pp/local/lib/python2.6/site-packages/mwlib-0.12.14-py2.6-linux-x86_64.egg/mwlib/apps/render.py",
line 177, in __call__ writer(env, output=tmpout, status_callback=self.status,
**writer_options) File
"/home/pp/local/lib/python2.6/site-packages/mwlib.zim-0.1.0-py2.6.egg/mwlib/zim/zimwriter.py",
line 219, in writer src = ZIPArticleSource(env, status_callback) File
"/home/pp/local/lib/python2.6/site-packages/mwlib.zim-0.1.0-py2.6.egg/mwlib/zim/zimwriter.py",
line 44, in __init__ self.coll = coll_from_zip(self.tmpdir, zipfn) File
"/home/pp/local/lib/python2.6/site-packages/mwlib.zim-0.1.0-py2.6.egg/mwlib/zim/collection.py",
line 293, in coll_from_zip wp.canonical_url =
urlparse.urljoin(item._env.wiki.siteinfo['general']['base'],
urllib2.quote(title.replace(' ', '_'))) File
"/home/pp/local/lib/python2.6/urllib.py", line 1222, in quote res =
map(safe_map.__getitem__, s) KeyError: u'\xe9' in function system, file
/home/pp/local/lib/python2.6/site-packages/mwlib-0.12.14-py2.6-linux-x86_64.egg/EGG-INFO/scripts/nslave.py,
line 37
I've verified that this happens on other collections as well.
--
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 29926] request a delink or debracket magic word
https://bugzilla.wikimedia.org/show_bug.cgi?id=29926
--- Comment #3 from Gustavo 2011-07-20 03:07:20 UTC ---
(In reply to comment #1)
> figure out what format it takes, and use that. Be consistent; if you see
> errors, edit and fix them.
(and in reply to bug 29970#c1)
> Again I recommend correctly factoring the template & template parameters to
> begin with.
Brion, you do not seem to think so about {{lc:}} and {{uc:}}. What's the main
and wider use of those functions? It's to normalize and facilitate comparison
of parameters, isn't it?
{{#ifeq: {{lc:{{{1} | foo |yes|no}} is more effective that a simple
{{#ifeq: {{{1}}} | foo |yes|no}}
Same happens here:
{{#ifeq: {{delink:{{{1} | foo |yes|no}} will be more effective that a
simple
{{#ifeq: {{{1}}} | foo |yes|no}}
I can't see the condition that makes this function invalid. As any other
function, it should be used where is needed and being consistent, of course.
--
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 29972] New: Malformed header errors with the new installer
https://bugzilla.wikimedia.org/show_bug.cgi?id=29972 Web browser: --- Bug #: 29972 Summary: Malformed header errors with the new installer Product: MediaWiki Version: 1.17.0 Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: Installation AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: emufarm...@gmail.com CC: innocentkil...@gmail.com Classification: Unclassified I've seen two reports of the same problem: http://www.mwusers.com/forums/showthread.php?17142-Internal-Server-Error-During-Upgrade http://www.mwusers.com/forums/showthread.php?17187-Upgrade-to-1.17.0-covert-tables-problem-and-inconsistent-page-layout "malformed header from script. Bad header=...have pagelinks; skipping ol" Seems goofy. -- 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 29928] show translated titles per user language
https://bugzilla.wikimedia.org/show_bug.cgi?id=29928 --- Comment #3 from Dan Collins 2011-07-20 02:17:25 UTC --- We actually mean langlinks, not iwlinks. iwlinks is inline links to other wikis, which could be to entirely unrelated pages, langlinks is the left sidebar's list. langlinks has the advantage of being indexed by language, so here's basically how that would happen. If a wiki has translate titles enabled ($wgTranslateTitles or something), then somewhere in Title.php we could probably do a lookup against the langlinks table, perhaps based on "select ll_title from langlinks where ll_from = $this->mArticleID and ll_lang = $wgLang->getCode();". That's the simple easy way, at least. that doesn't require a schema change or parser hacks. If the interlanguage links were going to have a new format, like [[de:Page (disambig)|Page]], we could have a new column in the langlinks for the translated title, and the parser would need to handle a new syntax or two. Of course, none of this takes into account allowing these titles to be used in search or urls. I don't know one bit about how search works, but if URLs were going to support it there would need to be some sort of conflict resolution between multiple pages with the same translatedtitle either in the same or different languages. And of course, if you actually meant iwlinks (using [[:de:stuff|otherstuff]] instead of [[de:stuff|otherstuff]]) then I'd be interested in hearing justification for that, but I don't really think it would work. -- 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 27968] JavaScript (geoip lookups) included via plain HTTP on HTTPS sites
https://bugzilla.wikimedia.org/show_bug.cgi?id=27968 Aryeh Gregor changed: What|Removed |Added CC||Simetrical+wikibugs@gmail.c ||om --- Comment #12 from Aryeh Gregor 2011-07-20 01:45:14 UTC --- In Chrome 14 dev, when visiting https://test.wikipedia.org/, I receive a message bar at the top of every page: "Insecure script has been blocked." There's a button that says "Load anyway (not recommended)". So users of Chrome are going to be getting a warning on every page, and the script won't work for them. Seems like it should be a blocker for broader HTTPS deployment. (I don't know if non-dev channels have the warning, but if they don't, they presumably will within a matter of weeks.) -- 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 18831] Wikibugs should use real name instead of e-mail prefix when reporting on IRC
https://bugzilla.wikimedia.org/show_bug.cgi?id=18831 MZMcBride changed: What|Removed |Added AssignedTo|b...@mzmcbride.com |m...@everybody.org -- 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 18831] Wikibugs should use real name instead of e-mail prefix when reporting on IRC
https://bugzilla.wikimedia.org/show_bug.cgi?id=18831 MZMcBride changed: What|Removed |Added Attachment #8617|0 |1 is obsolete|| Status|RESOLVED|REOPENED Resolution|FIXED | AssignedTo|wikibugs-l@lists.wikimedia. |b...@mzmcbride.com |org | --- Comment #9 from MZMcBride 2011-07-20 01:26:03 UTC --- Created attachment 8805 --> https://bugzilla.wikimedia.org/attachment.cgi?id=8805 Untested patch to fix the "real name" issue without using so much regex hackery Re-opening this. The regex currently in use is causing strangeness such as "Brion Vibber https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. You are the assignee for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 29928] show translated titles per user language
https://bugzilla.wikimedia.org/show_bug.cgi?id=29928 --- Comment #2 from Rd232 2011-07-20 00:32:37 UTC --- iwlinks made a certain sense to me, with an option to override the iwlink for the title if necessary (eg [[:de:Foo]] would use Foo for the German title, [[:de:Foo (bar)|Foo2]] would use Foo2, and [[:de:|Foo3]] would use Foo3, for the case where no target interwiki exists). However, it occurs to me that while this would work fine for page titles for the page the user is on, I'm not sure how it would work for page titles when looking at a category listing - which is an important aspect of the issue. I don't know a solution! In an answer to your question, I'd certainly settle for page title being displayed in the user's language; but searchable/linkable would be helpful. -- 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 27574] PDF export: Use LaTeX formulas instead of inline images
https://bugzilla.wikimedia.org/show_bug.cgi?id=27574 Brion Vibber changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Comment #6 from Brion Vibber 2011-07-20 00:08:39 UTC --- I'm reopening this as I agree that the bitmap math is not really very nice. It looks like the PDF output gets something circa 150dpi, which may be ok for on-screen reading (depending on how the viewer scales them), but looks pretty bad when zoomed in or blown up. -- 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 29970] Better handling of linked parameters in parser functions
https://bugzilla.wikimedia.org/show_bug.cgi?id=29970 Brion Vibber changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Brion Vibber 2011-07-19 23:56:57 UTC --- This seems to mostly be a repeat of bug 29926. Hypothetically one could probably do this, but that'll mainly just increase the likelihood that something that's *not* a whole and unique link will also get thrown in there, and it still won't work. A parameter that is incorrectly filled with a single link could also be a single link with a reference, or two links, or an image, or something else. If you actually needed it to be a *page title* then make sure it's actually a page title, and don't invite random markup! Again I recommend correctly factoring the template & template parameters to begin with. -- 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 29967] Better support for viewing and downloading large files
https://bugzilla.wikimedia.org/show_bug.cgi?id=29967 --- Comment #2 from Brion Vibber 2011-07-19 23:50:53 UTC --- I definitely agree that this is an issue; people will usually expect to click through to a 'full-size' image that's somewhere in the single-digit megapixels, not something that'll allocate so much memory it crashes their browser or turns their photo editor or word processor into swapping hell. "Obvious well-placed text" usually won't be noticed; many people may not even really be aware what it means if they do see it, but many more will never even see it -- they'll just click through on the image and have their browser fall into a swapping death. Forcing a 'save as' is a bit tricky unfortunately; can be done by streaming the file through the application servers and adding a Content-Disposition header (as img_auth.php and thumb.php can), though that may be funky to do in context without losing caching. Broadly speaking I'd support a cleaner look with saner, safer default links and a friendlier way to select a size & trigger downloads. Photo sites like flickr sometimes do this better (though we wouldn't necessarily want to emulate every little feature of their layout!) -- 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 29830] Enable Extension:WikiLove on Hindi Wikipedia
https://bugzilla.wikimedia.org/show_bug.cgi?id=29830 --- Comment #18 from Ryan Kaldari 2011-07-19 23:38:02 UTC --- Is anyone working on the config localization for Hindi WikiLove? If not, the extension should be turned off until someone actually volunteers to handle this. -- 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 29971] New: Set wgUploadMissingFileUrl for nlwiki
https://bugzilla.wikimedia.org/show_bug.cgi?id=29971 Web browser: --- Bug #: 29971 Summary: Set wgUploadMissingFileUrl for nlwiki Product: Wikimedia Version: unspecified Platform: All URL: http://nl.wikipedia.org OS/Version: All Status: NEW Keywords: ops Severity: enhancement Priority: Unprioritized Component: Site requests AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: robinp.1...@gmail.com Classification: Unclassified Please set $wgUploadMissingFileUrl to 'http://commons.wikimedia.org/wiki/Special:Upload?uselang=nl' for nlwiki (Dutch Wikipedia). This is a temporary fix until r92598 goes live on WMF wikis. (It used to work with $wgUploadNavigationUrl only, which is set for nlwiki already.) Thanks! -- 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 29967] Better support for viewing and downloading large files
https://bugzilla.wikimedia.org/show_bug.cgi?id=29967 Dan Collins changed: What|Removed |Added CC||en.wp.s...@gmail.com --- Comment #1 from Dan Collins 2011-07-19 23:17:01 UTC --- I'm noticing that the link that I would click on to download the full version says: Full resolution (7,479 × 11,146 pixels, file size: 89.94 MB, MIME type: image/jpeg) I don't understand the following complaint: "I've had other users become very upset - and even revert me - when replacing low resolution images by higher resolution ones, on the grounds that "the high res ones take too long/cost too much to download"." If higher resolution images are included in articles, then they are thumbnailed prior to rendering. If the users are complaining about the image on the description page, then there is an option in Special:Preferences to limit the size of that image. If users are complaining that the full-res image is too large, then they should read the descriptive, obvious, and well-placed text right next to the full resolution link that gives the size of the image both in pixels and in bytes. Further, as a commentor on that thread indicates, a gadget already exists which allows users who specifically need higher-than-article-resolution but not full-resolution images to download images at a specific scaled down size, and those sizes can be configured to a user's needs. By the design of our image presentation, every place a user will come across an image, they find a scaled down image, which they can set limitations on the size of. The only place where a user can not configure a limit on the size of an image is the full resolution link, which clearly states what the user is getting. If they accidentally click that and then realize what they did wrong, they can click the back button or cancel the download. If they can not handle even the smallest configurable thumbnail size, we generally try to make sure that wikis will behave well on text-only browsers. There is no missing functionality. 'Workarounds' for this problem include using the preferences made available under Appearance->Files, using the gadget mentioned at your last link, and reading the text next to the full resolution link before clicking it. Did I miss anything? -- 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 29961] Special:Export of a single page with huge history occasionally forgets and closing tags
https://bugzilla.wikimedia.org/show_bug.cgi?id=29961 Dan Collins changed: What|Removed |Added CC||en.wp.s...@gmail.com --- Comment #4 from Dan Collins 2011-07-19 23:02:12 UTC --- Probably that some more horrible thing happened. We're not unfamiliar with import and export crashing spontaneously on certain revisions, and it would be reasonable to assume that if export choked on a revision, it would simply stop output, resulting in no closing page tag, but with the last successfully exported revision being fully output. Did the pages get fully exported? -- 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 29928] show translated titles per user language
https://bugzilla.wikimedia.org/show_bug.cgi?id=29928 Dan Collins changed: What|Removed |Added CC||en.wp.s...@gmail.com Component|Parser |Internationalization --- Comment #1 from Dan Collins 2011-07-19 22:58:16 UTC --- This is an i18n bug (or possibly user interface), not a parser one. How do you suggest that translated titles be input? This could be done with JS (I know I have a userscript on enwiki that colors titles based on their article grade) or using iwlinks (shot down because article titles can contain other stuff - disambig, etc. - and not all articles exist crosslanguage) or using some new way of encoding it in the page text (woo, a more bloated parser) or using some new way of encoding it in the database (woo, a schema change and new special page and permission). Something to consider is whether it is sufficient for a page title to be displayed in the user's language or whether it must also be searchable/linkable. -- 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 29969] Protocol-relative URLs in ResourceLoader (CSSMin)
https://bugzilla.wikimedia.org/show_bug.cgi?id=29969 --- Comment #5 from Roan Kattouw 2011-07-19 22:48:12 UTC --- Strange. I also have $wgServer set to a protocol-relative URL, which will make your wiki explode on 1.17 or lower. Maybe it's that, or maybe something changed. -- 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 29969] Protocol-relative URLs in ResourceLoader (CSSMin)
https://bugzilla.wikimedia.org/show_bug.cgi?id=29969 --- Comment #4 from Laurence 'GreenReaper' Parry 2011-07-19 21:46:21 UTC --- Not true! $wgStylePath was protocol-relative. $wgExtensionAssetsPath wasn't set at all. I tried setting it and it didn't seem to make any difference (not that I'd expect it to for a wiki-sourced CSS file anyway). Now, I'm using this on 1.17, so maybe this has been fixed in the meantime. -- 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 20643] Serve SSL/HTTPS sites out of same domain names as HTTP access: https://en.wikipedia.org/
https://bugzilla.wikimedia.org/show_bug.cgi?id=20643 Bug 20643 depends on bug 29969, which changed state. Bug 29969 Summary: Protocol-relative URLs in ResourceLoader (CSSMin) https://bugzilla.wikimedia.org/show_bug.cgi?id=29969 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED -- 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 29969] Protocol-relative URLs in ResourceLoader (CSSMin)
https://bugzilla.wikimedia.org/show_bug.cgi?id=29969 Roan Kattouw changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Roan Kattouw 2011-07-19 21:30:07 UTC --- Whoops, this actually already works for me. I have $wgStylePath and $wgExtensionAssetsPath set to protocol-relative URLs, and GreenReaper didn't. -- 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 29969] Protocol-relative URLs in ResourceLoader (CSSMin)
https://bugzilla.wikimedia.org/show_bug.cgi?id=29969 --- Comment #2 from Roan Kattouw 2011-07-19 20:58:18 UTC --- (In reply to comment #1) > Preferably there would be no need to cache separate HTTP and HTTPS copies, I agree, that's what we're also aiming for for our future WMF HTTPS setup. > or > even let Apache know that the request is HTTPS (Varnish is told this via an > X-HTTPS header to allow it to handle some redirects appropriately). On WMF, MediaWiki will be aware of that it's being invoked over HTTPS (it needs to be, to send secure cookies) using X-Forwarded-Proto. Other than that, our SSL termination setup is similar to yours. -- 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 29968] Enable XFN rel=me for links on User Profile pages and rel="author" links on topic articles
https://bugzilla.wikimedia.org/show_bug.cgi?id=29968 --- Comment #4 from Paul Lindner 2011-07-19 20:55:46 UTC --- rel=.. is not currently allowed. We're looking at making rel attributes available as a query param for places like this where this type of markup is not allowed. Regarding rel="author" -- For wikipedia we'd go the extra mile :) Adding rel="author" to the history pages would probably be sufficient. I believe there's also an update stream where this data could be slotted. Cheers, paul -- 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 29968] Enable XFN rel=me for links on User Profile pages and rel="author" links on topic articles
https://bugzilla.wikimedia.org/show_bug.cgi?id=29968 Derk-Jan Hartman changed: What|Removed |Added CC||hart...@videolan.org --- Comment #3 from Derk-Jan Hartman 2011-07-19 20:50:16 UTC --- wether or not someone adds rel="me"+googleaccount would of course be entirely their own decisions, such could be easily templated. once rel= passes the parser whitelisting (or does it already ?). "The second step involves adding rel="author" attributes to links from articles to the mediawiki profile pages." That's a bit tough though I think. Wikipedia articles usually don't include their authors. The authors are listed in the article's history page, which is rather a distinct entity from the article itself when seen from the outside. How would Google make the link between an article and the article history 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 29970] New: Better handling of linked parameters in parser functions
https://bugzilla.wikimedia.org/show_bug.cgi?id=29970
Web browser: ---
Bug #: 29970
Summary: Better handling of linked parameters in parser
functions
Product: MediaWiki
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: Unprioritized
Component: Parser
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: gustron...@gmail.com
Classification: Unclassified
Handling and comparison of already-linked parameters are sometimes necessary.
Just see these unexpected results:
*{{TALKPAGENAME: [[Foo]] }} → (expected Talk:Foo)
*{{#ifexist: [[Piano]] |yes|no}} → no (expected yes)
*{{NAMESPACE:[[Help:Bar]]}} → (expected Help)
*{{fullurl:[[Article]]|query}} →(expected proper url)
I request the addition of automatic delinking capability to all parser
functions, proved that the parameter is a whole and unique link (ie.
not a string with some portions linked).
--
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 29969] Protocol-relative URLs in ResourceLoader (CSSMin)
https://bugzilla.wikimedia.org/show_bug.cgi?id=29969 --- Comment #1 from Laurence 'GreenReaper' Parry 2011-07-19 20:48:55 UTC --- To provide further insight on caching, my use case is: Apache (serving privately on http port 81) talking to Varnish (serving publicly on port 80) - Squid could be here too with Pound (serving publicly on port 443, directing requests to the Varnish cache) Preferably there would be no need to cache separate HTTP and HTTPS copies, or even let Apache know that the request is HTTPS (Varnish is told this via an X-HTTPS header to allow it to handle some redirects appropriately). -- 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 20643] Serve SSL/HTTPS sites out of same domain names as HTTP access: https://en.wikipedia.org/
https://bugzilla.wikimedia.org/show_bug.cgi?id=20643 Roan Kattouw changed: What|Removed |Added Depends on||29969 -- 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 29969] New: Protocol-relative URLs in ResourceLoader (CSSMin)
https://bugzilla.wikimedia.org/show_bug.cgi?id=29969 Web browser: --- Bug #: 29969 Summary: Protocol-relative URLs in ResourceLoader (CSSMin) Product: MediaWiki Version: 1.19-svn Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: Resource Loader AssignedTo: roan.katt...@gmail.com ReportedBy: roan.katt...@gmail.com CC: greenrea...@hotmail.com, roan.katt...@gmail.com Blocks: 20643 Classification: Unclassified CSSMin expands URLs to images and such when it does path rewriting. It also runs these paths through wfExpandUrl(), which means they will usually end up starting with http:// (even with a protocol-relative $wgServer). We can't use magic request protocol-based switching between http and https either due to caching, so we should just output protocol-relative (or even URLs relative to the root? I think there's a reason we don't do that but I forget) URLs here. Reported by GreenReaper (CC). -- 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 29968] Enable XFN rel=me for links on User Profile pages and rel="author" links on topic articles
https://bugzilla.wikimedia.org/show_bug.cgi?id=29968 --- Comment #2 from Paul Lindner 2011-07-19 20:39:17 UTC --- There's an existing XFN plugin here: http://www.mediawiki.org/wiki/Extension:Link_Attributes However I think this would enable rel= attributes globally, which would be a bad thing to do. Would be happy to send you patches, however some indication of what you'd be willing to accept would be appreciated. -- 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 29968] Enable XFN rel=me for links on User Profile pages and rel="author" links on topic articles
https://bugzilla.wikimedia.org/show_bug.cgi?id=29968 Reedy changed: What|Removed |Added CC||s...@reedyboy.net --- Comment #1 from Reedy 2011-07-19 20:36:15 UTC --- Of course we accept patches ;) FYI, HTML5 is not currently enabled on Wikimedia Sites. See bug 19719 for HTML5 issues, and bug 27478 for enabling it on WMF wikis -- 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 29968] Enable XFN rel=me for links on User Profile pages and rel="author" links on topic articles
https://bugzilla.wikimedia.org/show_bug.cgi?id=29968 Reedy changed: What|Removed |Added Severity|normal |enhancement -- 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 29968] New: Enable XFN rel=me for links on User Profile pages and rel="author" links on topic articles
https://bugzilla.wikimedia.org/show_bug.cgi?id=29968 Web browser: --- Bug #: 29968 Summary: Enable XFN rel=me for links on User Profile pages and rel="author" links on topic articles Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: Page editing AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: plind...@google.com Classification: Unclassified Hi, XFN (XHTML Friends Network) and HTML5 define a standard way for authors and accounts to link identity and authorship on the web. Right now the link editor on mediawiki does not have the ability to add the rel="me" markup needed by an author to link to their other accounts. If rel="me" markup is available we could allow wikipedia authors to participate in the Google Authorship program: http://www.google.com/support/webmasters/bin/answer.py?answer=1229920 The second step involves adding rel="author" attributes to links from articles to the mediawiki profile pages. Please feel free to contact me if you have questions or want to work more closely on this. Paul plind...@google.com -- 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 29926] request a delink or debracket magic word
https://bugzilla.wikimedia.org/show_bug.cgi?id=29926
Gustavo changed:
What|Removed |Added
CC||gustron...@gmail.com
--- Comment #2 from Gustavo 2011-07-19 20:15:12 UTC ---
(In reply to comment #1)
I agree about getting the template straight: In a given field, values must
sometimes be showed as links and sometimes not, and that condition is defined
in tags. It's ok. Now suppose you pretend evaluate that bunch of values to gate
another condition, not simple *to show* them.
Handling and comparison of already-linked parameters are sometimes necessary.
Just see these unexpected results with pagenames parser functions:
*{{TALKPAGENAME: [[Foo]] }} → (expected Talk:Foo)
*{{#ifexist: [[Piano]] |yes|no}} → no (expected yes)
*{{NAMESPACE:[[Help:Bar]]}} → (expected Help)
Brion: Please consider adding automatic delinking capability to all parser
functions instead, proved that the parameter is a whole and unique link (ie.
not a string with some portions linked).
I'll enter this as a different bug.
--
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 29967] New: Better support for viewing and downloading large files
https://bugzilla.wikimedia.org/show_bug.cgi?id=29967 Web browser: --- Bug #: 29967 Summary: Better support for viewing and downloading large files Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Unprioritized Component: Images and files AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: d...@moonflare.com CC: bryan.tongm...@gmail.com Classification: Unclassified Created attachment 8804 --> https://bugzilla.wikimedia.org/attachment.cgi?id=8804 Mock-up of view/download options pop up window. I've uploaded a number of very large images approaching the file size limit to Wikimedia Commons. An 90 MB, 83 megapixel example, used in about 2000 articles, is shown here: http://commons.wikimedia.org/wiki/File:Mona_Lisa,_by_Leonardo_da_Vinci,_from_C2RMF_retouched.jpg I've received complaints from users who wish to download the image but find it is too time-consuming or expensive to do so, or that the images occupy too much memory to load and view/edit on their computer. Some users click on the image on the file description page and accidentally find themselves downloading a very large file, which is problematic when they pay a lot for bandwidth, and sometimes it crashes or hangs their browser (or simply fails to display). The Download button feature allows downloads of thumbnails, but only goes up to 1024 px wide and is not available in Internet Explorer or on other wikis. I'm proposing a change in which: * Each user has a maximum download size (a user preference, default for logged-out users: 3 MB). Below this size, the current behavior occurs when clicking on an image. Above this size, clicking on an image will pop up a "view and download options" window. * The view and download options pop up window offers several download links (see my mock up at http://commons.wikimedia.org/wiki/File:Wikimedia_Commons_download_for_large_files_mock-up.png, also attached). In my example, 5 options are given, 1024 px wide, 1280 px wide, 10 megapixels, 20 megapixels, and full size. * Many browsers are not able to view very large images (e.g. over 30 megapixels) inline without breaking due to the memory needed to hold the decoded image. When downloading images over a certain megapixel size, the link should automatically Save As, rather than viewing in browser. * This feature should be available on all file description pages on all wikis, including pages that show files that are actually stored on Commons. See http://commons.wikimedia.org/wiki/Commons:Village_pump#Better_support_for_downloading_of_large_images for a thread on this (will update this link once the thread is archived). There doesn't appear to be any opposition on Commons to the idea at this stage. -- 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 29957] Special:CentralAuth shows time in UTC
https://bugzilla.wikimedia.org/show_bug.cgi?id=29957 Derk-Jan Hartman changed: What|Removed |Added Attachment #8803|0 |1 is patch|| Attachment #8803|application/octet-stream|text/plain mime type|| -- 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 29957] Special:CentralAuth shows time in UTC
https://bugzilla.wikimedia.org/show_bug.cgi?id=29957 Derk-Jan Hartman changed: What|Removed |Added Keywords||patch CC||hart...@videolan.org -- 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 29957] Special:CentralAuth shows time in UTC
https://bugzilla.wikimedia.org/show_bug.cgi?id=29957 --- Comment #2 from Derk-Jan Hartman 2011-07-19 18:53:28 UTC --- Created attachment 8803 --> https://bugzilla.wikimedia.org/attachment.cgi?id=8803 localtimezone patch Patch; Untested due to "who the hell runs a CentralAuth setup at home"-situation. -- 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 29966] central auth renders blocklog summary incorrectly
https://bugzilla.wikimedia.org/show_bug.cgi?id=29966 --- Comment #1 from Derk-Jan Hartman 2011-07-19 18:50:18 UTC --- Created attachment 8802 --> https://bugzilla.wikimedia.org/attachment.cgi?id=8802 log edit summary -- 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 29966] New: central auth renders blocklog summary incorrectly
https://bugzilla.wikimedia.org/show_bug.cgi?id=29966 Web browser: Apple Safari Bug #: 29966 Summary: central auth renders blocklog summary incorrectly Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: CentralAuth AssignedTo: vasi...@gmail.com ReportedBy: hart...@videolan.org CC: agarr...@wikimedia.org Classification: Unclassified Created attachment 8801 --> https://bugzilla.wikimedia.org/attachment.cgi?id=8801 blocklog in centralauth -- 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 29965] New: Error in CentralAuth table for test wiki
https://bugzilla.wikimedia.org/show_bug.cgi?id=29965 Web browser: Apple Safari Bug #: 29965 Summary: Error in CentralAuth table for test wiki Product: MediaWiki extensions Version: any Platform: All URL: http://en.wikipedia.org/w/index.php?title=Special%3ACe ntralAuth&target=TheDJ OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: CentralAuth AssignedTo: vasi...@gmail.com ReportedBy: hart...@videolan.org CC: agarr...@wikimedia.org Classification: Unclassified Created attachment 8800 --> https://bugzilla.wikimedia.org/attachment.cgi?id=8800 screenshot of the display problem Display name for test wiki is incorrect. Can be in Database/Configuration, or in CentralAuth extension. -- 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 27559] Preserve tab selection after submit in [[Special:Preferences]]
https://bugzilla.wikimedia.org/show_bug.cgi?id=27559 Bug 27559 depends on bug 29672, which changed state. Bug 29672 Summary: use tab name, not tab index for anchors on Special:Preferences https://bugzilla.wikimedia.org/show_bug.cgi?id=29672 What|Old Value |New Value Status|REOPENED|RESOLVED Resolution||FIXED -- 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 29672] use tab name, not tab index for anchors on Special:Preferences
https://bugzilla.wikimedia.org/show_bug.cgi?id=29672
duplicate...@googlemail.com changed:
What|Removed |Added
Status|REOPENED|RESOLVED
CC||duplicate...@googlemail.com
Resolution||FIXED
--- Comment #11 from duplicate...@googlemail.com 2011-07-19 18:40:24 UTC ---
(In reply to comment #10)
> Nice, but could you please add a legacy function for old links (from FAQ etc,
> links that help-seeking users found in archives)? Maybe something like
> (untested)
> var tab, hash = window.location.hash;
> if( tab = hash.match( /^#preftab-(.+)/ ) ) {
> var $tab = $( hash + '-tab' );
> if (! $tab.length && tab[1])
> $tab = $('#preftoc a').eq(parseInt(tab[1]));
> $tab.click();
> }
For backward compatible see r91869#c19481
--
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 29613] ike-cans - Eastern Canadian (Unified Canadian Aboriginal Syllabics) is too damn long
https://bugzilla.wikimedia.org/show_bug.cgi?id=29613 Ryan Kaldari changed: What|Removed |Added Resolution|WONTFIX |FIXED -- 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 29613] ike-cans - Eastern Canadian (Unified Canadian Aboriginal Syllabics) is too damn long
https://bugzilla.wikimedia.org/show_bug.cgi?id=29613 --- Comment #3 from Ryan Kaldari 2011-07-19 18:24:04 UTC --- Actually it looks like the CLDR data doesn't include ike. It was coming from our LocalNamesEn.php file all along. Fixed in r92548. -- 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 29954] Add API method for TitleBlacklist
https://bugzilla.wikimedia.org/show_bug.cgi?id=29954 --- Comment #5 from Reedy 2011-07-19 18:14:42 UTC --- Having a hook, or some relevant global, would allow things to be able to grab into the validation logic, rather than into our somewhat convoluted methods that end up into the extensions as is. Something to look at later definitely -- 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 29954] Add API method for TitleBlacklist
https://bugzilla.wikimedia.org/show_bug.cgi?id=29954 --- Comment #4 from Ian Baker 2011-07-19 18:01:32 UTC --- Yeah, invoking page creation hooks without creating a page sounds clever, but also fragile. Like, if it works now, there's no guarantee that a future extension won't break it by using those hooks to invoke DML. I'd be into the notion of making a generic API that, if existing validation classes are present, will call them all and aggregate the results. It would require new code for each validation extension, but it'd allow us to at least centralize that, rather than having each new consumer of the data implement all of them separately. At the moment, though, I think I'm going to build a TitleBlacklist API. We can move that very same code into a more generic API when/if we need to add support for a second validation extension. -- 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 28986] the code to normalize widths of images in Linker is scary and really belongs somewhere else.
https://bugzilla.wikimedia.org/show_bug.cgi?id=28986 Derk-Jan Hartman changed: What|Removed |Added AssignedTo|hart...@videolan.org|wikibugs-l@lists.wikimedia. ||org -- 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 29960] Allowed memory size of 134217728 bytes exhausted
https://bugzilla.wikimedia.org/show_bug.cgi?id=29960 --- Comment #4 from Christian Kujau 2011-07-19 17:23:25 UTC --- With wgSecurityUseDBHook, the error 500 persists, but PHP does not seem to exceed its memory_limit any more. So the error 500 must be something different. However, with wgSecurityUseDBHook disabled, wgPageRestrictions won't work any more and all the restricted sites are readable to the world - so that's not a feasible workaround. -- 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 29964] Add $2 parameter to message Mwe-upwiz-source-thirdparty-license
https://bugzilla.wikimedia.org/show_bug.cgi?id=29964 Neil Kandalgaonkar changed: What|Removed |Added Priority|Unprioritized |Low -- 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 29964] New: Add $2 parameter to message Mwe-upwiz-source-thirdparty-license
https://bugzilla.wikimedia.org/show_bug.cgi?id=29964 Web browser: --- Bug #: 29964 Summary: Add $2 parameter to message Mwe-upwiz-source-thirdparty-license Product: MediaWiki extensions Version: any Platform: All URL: http://www.mediawiki.org/wiki/I18n#Pass_number_of_list _items_as_parameters_to_messages_talking_about_lists OS/Version: All Status: NEW Severity: trivial Priority: Unprioritized Component: UploadWizard AssignedTo: ne...@wikimedia.org ReportedBy: bugzilla.wikime...@publi.purodha.net CC: asha...@wikimedia.org, bugzilla.wikime...@publi.purodha.net Classification: Unclassified The message MediaWiki:Mwe-upwiz-source-thirdparty-license ends with the word "license(s)" which should be avoided by adding another parameter: $2 - number of items in the list following the message. I tried to amend the source myself but was unable to spot the place where the message is being used in the svn repository. See also http://www.mediawiki.org/wiki/I18n#Pass_number_of_list_items_as_parameters_to_messages_talking_about_lists -- 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 29961] Special:Export of a single page with huge history occasionally forgets and closing tags
https://bugzilla.wikimedia.org/show_bug.cgi?id=29961 --- Comment #3 from Nemo_bis 2011-07-19 17:15:37 UTC --- A fatal error that has as effect only those two missing tags, or do you mean that perhaps some more horrible thing happened (for instance some missing revisions)? Files are here: http://www.archive.org/details/wiki.guildwars.com Now I'll check the revisions and I'll try to contact sysadmins. -- 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 29926] request a delink or debracket magic word
https://bugzilla.wikimedia.org/show_bug.cgi?id=29926 Brion Vibber changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Brion Vibber 2011-07-19 16:44:20 UTC --- I would recommend just getting the template straight -- figure out what format it takes, and use that. Be consistent; if you see errors, edit and fix them. -- 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 29961] Special:Export of a single page with huge history occasionally forgets and closing tags
https://bugzilla.wikimedia.org/show_bug.cgi?id=29961 --- Comment #2 from Brion Vibber 2011-07-19 16:42:08 UTC --- If you have direct server access or can reach the site admin, check the web server error logs for messages. -- 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 29961] Special:Export of a single page with huge history occasionally forgets and closing tags
https://bugzilla.wikimedia.org/show_bug.cgi?id=29961 --- Comment #1 from Brion Vibber 2011-07-19 16:40:23 UTC --- This probably indicates a fatal PHP error during output... -- 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 29906] Edit by a non-(auto)-reviewer flagged automatically
https://bugzilla.wikimedia.org/show_bug.cgi?id=29906 --- Comment #8 from Aaron Schulz 2011-07-19 16:37:20 UTC --- On the topic of config changes: I can make it so that the *total* count of reverted edits are subtracted from the "checkedEdits" count. This would be conservative though, since some of the reverted edits would be to things like Talk pages and such. I can also add a 'maxRevertedEdits' parameter to $wgFlaggedRevsAutoconfirm. -- 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 12261] Render category links as an HTML list
https://bugzilla.wikimedia.org/show_bug.cgi?id=12261 --- Comment #15 from Bergi 2011-07-19 16:28:54 UTC --- Thanks. I just wanted to start arguing for the changes already made in r92245 :-) -- 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 29672] use tab name, not tab index for anchors on Special:Preferences
https://bugzilla.wikimedia.org/show_bug.cgi?id=29672
Bergi changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC||a.d.be...@web.de
Resolution|FIXED |
--- Comment #10 from Bergi 2011-07-19 16:06:39 UTC ---
Nice, but could you please add a legacy function for old links (from FAQ etc,
links that help-seeking users found in archives)? Maybe something like
(untested)
var tab, hash = window.location.hash;
if( tab = hash.match( /^#preftab-(.+)/ ) ) {
var $tab = $( hash + '-tab' );
if (! $tab.length && tab[1])
$tab = $('#preftoc a').eq(parseInt(tab[1]));
$tab.click();
}
--
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 27559] Preserve tab selection after submit in [[Special:Preferences]]
https://bugzilla.wikimedia.org/show_bug.cgi?id=27559 Bug 27559 depends on bug 29672, which changed state. Bug 29672 Summary: use tab name, not tab index for anchors on Special:Preferences https://bugzilla.wikimedia.org/show_bug.cgi?id=29672 What|Old Value |New Value Status|RESOLVED|REOPENED Resolution|FIXED | -- 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 20257] SQLite support (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=20257 Bug 20257 depends on bug 25746, which changed state. Bug 25746 Summary: categories don't work with the sqlite backend? https://bugzilla.wikimedia.org/show_bug.cgi?id=25746 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||WORKSFORME -- 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 25746] categories don't work with the sqlite backend?
https://bugzilla.wikimedia.org/show_bug.cgi?id=25746 Max Semenik changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WORKSFORME --- Comment #5 from Max Semenik 2011-07-19 15:57:23 UTC --- No response, assuming it's due to antiquated SQLite version. I'll consider adding a warning when installing on anything less than 3.6. -- 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 29963] New: Switch to "Hide/Show editors user_groups" in Recent Changes
https://bugzilla.wikimedia.org/show_bug.cgi?id=29963
Web browser: ---
Bug #: 29963
Summary: Switch to "Hide/Show editors user_groups" in Recent
Changes
Product: MediaWiki
Version: unspecified
Platform: All
URL: http://ar.wikipedia.org/wiki/%D9%88%D9%8A%D9%83%D9%8A%
D8%A8%D9%8A%D8%AF%D9%8A%D8%A7:%D8%A7%D9%84%D9%85%D9%8A
%D8%AF%D8%A7%D9%86/%D8%A3%D8%B1%D8%B4%D9%8A%D9%81/%D8%
A7%D9%82%D8%AA%D8%B1%D8%A7%D8%AD%D8%A7%D8%AA/07/2011
OS/Version: All
Status: NEW
Severity: enhancement
Priority: Unprioritized
Component: Recent changes
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: slowcl...@gmail.com
Classification: Unclassified
We would like to request a new switch on the "special:RecentChanges" and/or
"Special:NewPages" which would give an ability to Hide users who granted an
editor flag or above,this switch is to make the list easier to track vandalism.
currently listing Hide/Show(minor edits |bots |anonymous users |logged-in users
|my edits)
we need +(editor users) switch to hide trusted editors.
i.e:(!("editor" in user_groups) &!("sysop" in user_groups)) in abuse filter
extension.
--
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 29940] Enable short NamespaceAliases in Hindi Wiki
https://bugzilla.wikimedia.org/show_bug.cgi?id=29940 --- Comment #5 from mayurkumar 2011-07-19 13:48:23 UTC --- Now can this be enabled on hindi wiki? -- 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 22043] install Extension:SpecialInterwiki in read-only mode on all WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=22043 --- Comment #8 from Robin Pepermans (SPQRobin) 2011-07-19 12:55:20 UTC --- Note that with r92529, editing through SpecialInterwiki is always disabled when $wgInterwikiCache is used. -- 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 22043] install Extension:SpecialInterwiki in read-only mode on all WMF wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=22043 --- Comment #7 from Robin Pepermans (SPQRobin) 2011-07-19 12:53:53 UTC --- The API and this extension now work with the interwiki cache, since r92528 and r92529. -- 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 19838] Missing interwiki prefixes
https://bugzilla.wikimedia.org/show_bug.cgi?id=19838 Robin Pepermans (SPQRobin) changed: What|Removed |Added CC||lupo.bugzi...@gmail.com --- Comment #13 from Robin Pepermans (SPQRobin) 2011-07-19 12:33:16 UTC --- *** Bug 29962 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 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 29962] Interwikimap does not contain "ckb", but it's treated as valid interlanguage prefix
https://bugzilla.wikimedia.org/show_bug.cgi?id=29962 Robin Pepermans (SPQRobin) changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Robin Pepermans (SPQRobin) 2011-07-19 12:33:16 UTC --- *** This bug has been marked as a duplicate of bug 19838 *** -- 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 19838] Missing interwiki prefixes
https://bugzilla.wikimedia.org/show_bug.cgi?id=19838 Robin Pepermans (SPQRobin) changed: What|Removed |Added Status|NEW |RESOLVED CC||robinp.1...@gmail.com Resolution||FIXED --- Comment #12 from Robin Pepermans (SPQRobin) 2011-07-19 12:31:43 UTC --- Patch applied in r92528 (modified to work with current code). -- 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 29962] Interwikimap does not contain "ckb", but it's treated as valid interlanguage prefix
https://bugzilla.wikimedia.org/show_bug.cgi?id=29962 Robin Pepermans (SPQRobin) changed: What|Removed |Added CC||robinp.1...@gmail.com --- Comment #1 from Robin Pepermans (SPQRobin) 2011-07-19 11:43:43 UTC --- That is most likely due to bug 19838. I was just working on fixing this, so that the API uses the interwiki cache. -- 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 27981] Award count not being incremented when an award is given out
https://bugzilla.wikimedia.org/show_bug.cgi?id=27981 Jack Phoenix changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #1 from Jack Phoenix 2011-07-19 11:38:02 UTC --- Fixed in r92525. -- 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 29962] New: Interwikimap does not contain "ckb", but it's treated as valid interlanguage prefix
https://bugzilla.wikimedia.org/show_bug.cgi?id=29962 Web browser: --- Bug #: 29962 Summary: Interwikimap does not contain "ckb", but it's treated as valid interlanguage prefix Product: MediaWiki Version: (wikimedia-deployment) Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: API AssignedTo: roan.katt...@gmail.com ReportedBy: lupo.bugzi...@gmail.com CC: bryan.tongm...@gmail.com, s...@reedyboy.net, soxre...@gmail.com, vasi...@gmail.com Classification: Unclassified Why does the interwikimap not contain ckb: http://commons.wikimedia.org/w/api.php?action=query&meta=siteinfo&siprop=interwikimap whereas it's evidently a valid interlanguage prefix: http://commons.wikimedia.org/w/api.php?action=query&prop=langlinks&titles=User:Lupo/ct http://ckb.wikipedia.org -- 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 29930] tag ends formatting early
https://bugzilla.wikimedia.org/show_bug.cgi?id=29930 foxyshadis changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #2 from foxyshadis 2011-07-19 11:32:49 UTC --- Sorry, I looked at the page on a system that uses different fonts, and I realized that I was wrong all along; the "paragraph" section just looked non-monospace because the fonts were too similar! It's one of those funny words that all letters are approximately the same width anyway. I feel sheepish now, sorry about that. -- 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 23898] [partner] Google maps needs to update it's license statement for Wikipedia
https://bugzilla.wikimedia.org/show_bug.cgi?id=23898 --- Comment #6 from Ashar Voultoiz 2011-07-19 10:44:45 UTC --- Great Tomasz thanks! -- 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 11142] blacklist extension handling is broken
https://bugzilla.wikimedia.org/show_bug.cgi?id=11142 Ashar Voultoiz changed: What|Removed |Added Status|RESOLVED|REOPENED CC||has...@free.fr Resolution|DUPLICATE | --- Comment #6 from Ashar Voultoiz 2011-07-19 10:43:25 UTC --- Reopening. Does not seem to be a dupe of bug 28609 -- 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 29906] Edit by a non-(auto)-reviewer flagged automatically
https://bugzilla.wikimedia.org/show_bug.cgi?id=29906 Michael M. changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #7 from Michael M. 2011-07-19 10:22:49 UTC --- Yes, he probably was in autoreview group at the time of the edit, which was correct according to the configuration. The only bug was that one in the API, which is fixed now and had nothing to do with flagged revisions. So this bug is invalid. I asked for comments about what the configuration should be on [[:de:Wikipedia Diskussion:Gesichtete Versionen]], if there is a consensus on changing the configuration or the wish for some other criteria to promote a user automatically to autoreview I'll open another bug for it. -- 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 29906] Edit by a non-(auto)-reviewer flagged automatically
https://bugzilla.wikimedia.org/show_bug.cgi?id=29906 --- Comment #6 from Aaron Schulz 2011-07-19 08:23:53 UTC --- So it looks like the user meet $wgFlaggedRevsAutoconfirm at the time. So this is not a bug. -- 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 29923] Install Q&A system at help.en.wikipedia.org
https://bugzilla.wikimedia.org/show_bug.cgi?id=29923 --- Comment #4 from Kozuch 2011-07-19 07:23:55 UTC --- (In reply to comment #3) > And I think the help.en thing should just be like a generic redirect, so we > don't need one installation per wiki etc... I basically think Q&A system within Wikimedia would be very useful. We can create one instance for whole Wikimedia (e.g. at help.wikimedia.org). The single site would have sections for different projects (Wikipedia, Commons etc.) within itself (kind of categorizing or tagging). Multilinguality could be solved within single installation too although I do not know if the above listed software supports it. -- 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
