[Bug 23030] New: Event- and timeline focus
https://bugzilla.wikimedia.org/show_bug.cgi?id=23030 Summary: Event- and timeline focus Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: SemanticResultFormats AssignedTo: denny.vrande...@kit.edu ReportedBy: jeroen_ded...@yahoo.com CC: wikibugs-l@lists.wikimedia.org Event- and timelines only allow to focus on the first, middle and last event. It would be extremely practical if they also could focus (center) on the current date and simply start at the current date. This limitation is causing problems on the http://0x20.be/ wiki, esp for people with small screen width. -- 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 16438] \varphi is not always displayed correctly
https://bugzilla.wikimedia.org/show_bug.cgi?id=16438 Conrad Irwin changed: What|Removed |Added Status|NEW |RESOLVED CC||conrad.ir...@gmail.com Resolution||WORKSFORME --- Comment #1 from Conrad Irwin 2010-04-02 22:23:51 UTC --- The page given no-longer seems broken. -- 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 4421] Image file extension should not be part of the name
https://bugzilla.wikimedia.org/show_bug.cgi?id=4421 --- Comment #69 from Aryeh Gregor 2010-04-02 21:09:01 UTC --- (In reply to comment #68) > I think you may be missing my point, and I also think you need to take a > closer > look at how things are currently done. > > Look here: > http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/MimeMagic.php?view=markup > (38 mime types, 9 with multiple file extensions) > > ...and here: > http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/mime.types?view=markup > (137 mime types, 36 with multiple file extensions) > > ...and here: > https://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/docs/conf/mime.types > (629 mime types, 86 with multiple file extensions) > > All current and future media types with multiple choices for file extension > would need to be hardcoded to specify the immutable preferred version. > Granted, not all or even most of these really matter, but even accounting for > that, it still leaves a lot of management headache ensuring things stay > "right". Hmm. You might be right, but denormalizing to this extent still doesn't seem like the best solution to me. If anything had to be in the database, we should be able to have a single 1:1 table mapping (img_major_mime, img_minor_mime) -> extension, not the same extension duplicated in millions of image rows. > r60772 isn't a preliminary version. It's a necessary portion of a complete > final version that would be needed regardless of whether storing extensions in > the database or using hardcoded extensions is the choice (or any other scheme, > for that matter). There are no database changes in r60772. No objection from me, then. It's true that I haven't looked closely at this -- I just don't have the time right now, so I only read the RFC. -- 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 4421] Image file extension should not be part of the name
https://bugzilla.wikimedia.org/show_bug.cgi?id=4421 --- Comment #68 from Rob Lanphier (RobLa) 2010-04-02 20:42:32 UTC --- > It's extremely hard for me to see why anyone would decide they prefer .jpeg to > .jpg (or vice versa) so much that they'd look through the source code, find > the > code that has the mapping, *and* ignore the comment warning them not to change > it. Even if they do something so pathologically stupid, it will be caught > quickly and isn't that hard to fix manually. I think you may be missing my point, and I also think you need to take a closer look at how things are currently done. Look here: http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/MimeMagic.php?view=markup (38 mime types, 9 with multiple file extensions) ...and here: http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/mime.types?view=markup (137 mime types, 36 with multiple file extensions) ...and here: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/docs/conf/mime.types (629 mime types, 86 with multiple file extensions) All current and future media types with multiple choices for file extension would need to be hardcoded to specify the immutable preferred version. Granted, not all or even most of these really matter, but even accounting for that, it still leaves a lot of management headache ensuring things stay "right". > No objection to checking in a preliminary version, but it wouldn't make any > sense to do a schema change only to decide we actually don't need it. r60772 isn't a preliminary version. It's a necessary portion of a complete final version that would be needed regardless of whether storing extensions in the database or using hardcoded extensions is the choice (or any other scheme, for that matter). There are no database changes in r60772. -- 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 23029] Need more ponies
https://bugzilla.wikimedia.org/show_bug.cgi?id=23029 Aryeh Gregor changed: What|Removed |Added CC||simetrical+wikib...@gmail.c ||om --- Comment #2 from Aryeh Gregor 2010-04-02 20:35:01 UTC --- It will be necessary to look into sanitation, zoning, and shipping laws to verify feasibility of widespread pony distribution. I suggest Wikimedia's counsel is contacted before substantial development resources are invested here. Note that Chromium attempted to implement a related feature, involving goats, and received some complaints: http://code.google.com/p/chromium/issues/detail?id=31482 -- 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 23029] Need more ponies
https://bugzilla.wikimedia.org/show_bug.cgi?id=23029 Soxred93 changed: What|Removed |Added Status|NEW |RESOLVED CC||soxre...@gmail.com Resolution||INVALID --- Comment #1 from Soxred93 2010-04-02 20:33:58 UTC --- April Fools was yesterday. -- 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 23029] New: Need more ponies
https://bugzilla.wikimedia.org/show_bug.cgi?id=23029 Summary: Need more ponies Product: MediaWiki Version: unspecified Platform: All URL: http://lists.wikimedia.org/pipermail/wikitech-l/2010-A pril/047494.html OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: General/Unknown AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: innocentkil...@gmail.com See URL. It would improve morale for everyone if Neil had a pony. I would like one too. -- 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 4421] Image file extension should not be part of the name
https://bugzilla.wikimedia.org/show_bug.cgi?id=4421 --- Comment #67 from Robert Rohde 2010-04-02 20:17:38 UTC --- (In reply to comment #64) > 2) Problem with the current system (not mentioned for a while): Google > apparently doesn't index image pages properly on non-Wikimedia MW installs, > because it assumes anything ending in .png/.jpeg/etc. is an image page, not an > HTML page. I wrote [[mw:Extension:FilePageMasking]] which transparently rewrites ".xxx" to "_xxx" for image description pages. This solves the Google problem by masking out the 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 4421] Image file extension should not be part of the name
https://bugzilla.wikimedia.org/show_bug.cgi?id=4421 --- Comment #66 from Aryeh Gregor 2010-04-02 19:53:24 UTC --- (In reply to comment #65) > There would need to be all sorts of red flags and warnings around the part of > the configuration/code that specifies that mapping, and if there's ever a > legitimate need to remap any extension, fixing it becomes pretty fragile. Hardcode it, not configurable. Add a comment if you're worried, saying "Do not change this or else existing files will become inaccessible". Even if you think developers will ignore the comment *and* no one else will notice in code review or testing, which seems excessively pessimistic, it will still be noticed immediately upon deployment, and fixed with minimal damage. If an end-user modifies the source code without knowing what they're doing, on the other hand, they deserve whatever happens to them. There are much more destructive things they can do to their wiki. > Mind you, it's not just JPEG that has multiple choices for filename, it's most > media types. Changing it on an existing wiki seems like it'd really screw > things up, and it's pretty easy to imagine someone trying it. It's extremely hard for me to see why anyone would decide they prefer .jpeg to .jpg (or vice versa) so much that they'd look through the source code, find the code that has the mapping, *and* ignore the comment warning them not to change it. Even if they do something so pathologically stupid, it will be caught quickly and isn't that hard to fix manually. > Regardless, the job of trying a different approach would be made easier by > getting some variant of r60772 checked in (as well as some of the other fixes > and tweaks on that branch), since I'm a little worried that there's more code > that's being checked in that glibly assumes article title==filename. The > sooner those bits are checked in, the easier it would be to maintain a branch > that implements the actual feature. No objection to checking in a preliminary version, but it wouldn't make any sense to do a schema change only to decide we actually don't need 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 4421] Image file extension should not be part of the name
https://bugzilla.wikimedia.org/show_bug.cgi?id=4421 --- Comment #65 from Rob Lanphier (RobLa) 2010-04-02 19:43:10 UTC --- > Why not just hardcode "jpg" as the preferred version, and never change it? > That seems a lot simpler and less error-prone than keeping track of it There would need to be all sorts of red flags and warnings around the part of the configuration/code that specifies that mapping, and if there's ever a legitimate need to remap any extension, fixing it becomes pretty fragile. The current mapping of image/jpeg->".jpeg" as preferred extension is in the mime.types file, which looks roughly compatible with the Apache mime.types file. Someone may naively copy an Apache file over and screw up their wiki if the ordering isn't the same. Mind you, it's not just JPEG that has multiple choices for filename, it's most media types. Changing it on an existing wiki seems like it'd really screw things up, and it's pretty easy to imagine someone trying it. That said, I'm not dug in on this approach. I can definitely see the benefit of not touching the database; in fact, it was my original strategy. Part of the reason why I went with the database approach was the recommendation in comment #28, the wisdom of which was borne out after I spent a fair amount of time trying to make the no-database-changes approach work. I understand the code better now, so I'd probably be more successful if I tried again - though I'm a little nervous I might just rediscover another reason why the database change was needed. As I recall, I think what tipped me over was taking a good look at how mime.types are configured. Regardless, the job of trying a different approach would be made easier by getting some variant of r60772 checked in (as well as some of the other fixes and tweaks on that branch), since I'm a little worried that there's more code that's being checked in that glibly assumes article title==filename. The sooner those bits are checked in, the easier it would be to maintain a branch that implements the actual feature. -- 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 20736] Commons' "Upload new version" acts as "Upload file" (Firefogg?)
https://bugzilla.wikimedia.org/show_bug.cgi?id=20736
--- Comment #12 from Jarry1250 2010-04-02 19:25:47 UTC ---
Just got exactly the same thing with Internet Explorer 8, uploaded to the wrong
location again. I should note that the interface ("Go to resource page") goes
straight to the actual target of the upload i.e. the bad filename.
--
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 20736] Commons' "Upload new version" acts as "Upload file" (Firefogg?)
https://bugzilla.wikimedia.org/show_bug.cgi?id=20736 Jarry1250 changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #11 from Jarry1250 2010-04-02 19:15:48 UTC --- Just happened to me again, in Google Chrome. http://commons.wikimedia.org/wiki/File:Mixed_incidence.jpg was supposed to be a new version of http://commons.wikimedia.org/wiki/File:Tax_incidence_(mixed).svg . Then, I hit my back button and tried again, and it uploaded it as a new version - of the wrong file! Eurgh. -- 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 21019] "Did you mean..." doesn't shows "Special" for the namespace -1
https://bugzilla.wikimedia.org/show_bug.cgi?id=21019 Chad H. changed: What|Removed |Added CC||innocentkil...@gmail.com Severity|enhancement |minor -- 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 15160] An option to disable fancy signature for a user group
https://bugzilla.wikimedia.org/show_bug.cgi?id=15160
Chad H. changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||innocentkil...@gmail.com
Resolution||WONTFIX
--- Comment #1 from Chad H. 2010-04-02 18:28:42 UTC
---
WONTFIX adding this a new core ability. This workaround in LocalSettings should
work:
---
$wgGroupPermissions['user']['fancysig'] = false;
$wgGroupPermissions['sysop']['fancysig'] = true;
$wgExtensionFunctions[] = 'efDisableFancySig';
function efDisableFancySig() {
global $wgUser;
if( !$wgUser->isAllowed( 'fancysig' ) ) {
global $wgHiddenPrefs;
$wgHiddenPrefs[] = 'fancysig';
}
}
---
--
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 4421] Image file extension should not be part of the name
https://bugzilla.wikimedia.org/show_bug.cgi?id=4421 --- Comment #64 from Aryeh Gregor 2010-04-02 17:20:30 UTC --- Okay, so: 1) Problem with the current system: Cannot upload a new version of a file in a different format while preserving history. 2) Problem with the current system (not mentioned for a while): Google apparently doesn't index image pages properly on non-Wikimedia MW installs, because it assumes anything ending in .png/.jpeg/etc. is an image page, not an HTML page. 3) Problem with the proposed system: Files are possible that have no extension, or a completely misleading extension, so it's not clear what general type of file they are (although sometimes this is unclear anyway). There are several possible solutions I can think of. The status quo solves (3) but not (1) or (2). The proposal solves (1) and (2) but not (3). I don't see any reason why we wouldn't want to allow the proposed changes as an option; some wiki admins will surely prefer the option, although others may not. It could be disabled by default. Another possibility is to require extensions as now, but allow upload of a new file to an existing filename of a different type. This would automatically rename the file to the new appropriate extension, and would only work if that's possible. Reverting to an earlier file of a different type would also change the name. This solves (1) and (3) but not (2). It would be a bit messy, but I think strictly better than the status quo. (In reply to comment #52) > Hi Aryeh: the reason I chose to store the file extension in addition to MIME > is > that both img_file_ext='jpg' or 'jpeg' are both valid values when > img_minor_mime is 'jpeg'. While one might be able to infer what the extension > would be based on the preferred extension given the MIME type, it's > potentially > a booby trap for devs and sysadmins down the road, who might unintentionally > corrupt a wiki by changing the preferred file extension from one to the > other. > What may seem like a harmless switch from "jpg" to "jpeg" as the preferred > extension would suddenly cause a lot of existing images, archive images, and > thumbnails to break. By storing this in the DB, changing the preferred > extension in the configuration/code is safe, with only future updates taking > on > the new preferred extension. Why not just hardcode "jpg" as the preferred version, and never change it? That seems a lot simpler and less error-prone than keeping track of 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 4421] Image file extension should not be part of the name
https://bugzilla.wikimedia.org/show_bug.cgi?id=4421 --- Comment #63 from MZMcBride 2010-04-02 16:30:30 UTC --- (In reply to comment #62) > > Of course it's not guaranteed to be correct (as the spec goes on to say), > > but > > it certainly does help. This is about human readability, not whether the > > file > > extension really matters. > > If that's the primary concern, then the right thing to do is to set up > "Image:", "Audio:" and "Video:" namespaces to distinguish between different > file types, rather than lumping them all in to "File:". Expecting > non-technical users to understand that ".svg" usually means a vector diagram > hardly serves the goal of readability. There may be a case for adding "Audio" and "Video" prefixes as aliases for "File", though it would probably cause conflicts with a fair number of installations that have already created separate namespaces with these prefixes. Implementing this feature (extensionless files) as a configurable option with the default off might be an option, though the required schema changes make it unlikely that many people would utilize it, I think. In general, it seems like removing the extensions causes far more problems than it solves. -- 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 4421] Image file extension should not be part of the name
https://bugzilla.wikimedia.org/show_bug.cgi?id=4421 --- Comment #62 from Rob Lanphier (RobLa) 2010-04-02 16:21:30 UTC --- > Of course it's not guaranteed to be correct (as the spec goes on to say), but > it certainly does help. This is about human readability, not whether the file > extension really matters. If that's the primary concern, then the right thing to do is to set up "Image:", "Audio:" and "Video:" namespaces to distinguish between different file types, rather than lumping them all in to "File:". Expecting non-technical users to understand that ".svg" usually means a vector diagram hardly serves the goal of readability. -- 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 22975] Chinese version does not display special pages properly
https://bugzilla.wikimedia.org/show_bug.cgi?id=22975 Alexandre Emsenhuber [IAlex] changed: What|Removed |Added Severity|blocker |major -- 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 4421] Image file extension should not be part of the name
https://bugzilla.wikimedia.org/show_bug.cgi?id=4421
--- Comment #61 from Chad H. 2010-04-02 16:06:42 UTC
---
(In reply to comment #60)
> > You still haven't explained how we're supposed to know what [[File:Name]] is
> > when looking at the syntax.
>
> You're not, as explained here:
> http://www.w3.org/TR/webarch/#uri-opacity
Agent's aren't supposed to infer anything. From the spec:
> The example URI used in the travel scenario ("http://weather.example.com
> /oaxaca") suggests to a human reader that the identified resource has
> something > to do with the weather in Oaxaca.
Of course it's not guaranteed to be correct (as the spec goes on to say), but
it certainly does help. This is about human readability, not whether the file
extension really matters.
--
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 4421] Image file extension should not be part of the name
https://bugzilla.wikimedia.org/show_bug.cgi?id=4421 --- Comment #60 from Rob Lanphier (RobLa) 2010-04-02 16:00:43 UTC --- > You still haven't explained how we're supposed to know what [[File:Name]] is > when looking at the syntax. You're not, as explained here: http://www.w3.org/TR/webarch/#uri-opacity -- 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 3646] RSS, Atom, XML syndication feeds (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=3646 Bug 3646 depends on bug 19393, which changed state. Bug 19393 Summary: Feeds format dates in content language and other messages in user language https://bugzilla.wikimedia.org/show_bug.cgi?id=19393 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 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 19393] Feeds format dates in content language and other messages in user language
https://bugzilla.wikimedia.org/show_bug.cgi?id=19393 Alexandre Emsenhuber [IAlex] changed: What|Removed |Added Status|NEW |RESOLVED CC||alex.emsenhu...@bluewin.ch Resolution||FIXED --- Comment #5 from Alexandre Emsenhuber [IAlex] 2010-04-02 15:47:18 UTC --- Done in r64521. -- 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 22238] Missing descriptions for actions in bugzilla
https://bugzilla.wikimedia.org/show_bug.cgi?id=22238 --- Comment #4 from Chad H. 2010-04-02 15:39:19 UTC --- >From dupe: buglist_sorted_by_relevance. -- 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 22238] Missing descriptions for actions in bugzilla
https://bugzilla.wikimedia.org/show_bug.cgi?id=22238 Chad H. changed: What|Removed |Added CC||happy-me...@live.com --- Comment #3 from Chad H. 2010-04-02 15:38:49 UTC --- *** Bug 22177 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 22177] unparsed message shown on search
https://bugzilla.wikimedia.org/show_bug.cgi?id=22177 Chad H. changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Chad H. 2010-04-02 15:38:49 UTC --- *** This bug has been marked as a duplicate of bug 22238 *** -- 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 4421] Image file extension should not be part of the name
https://bugzilla.wikimedia.org/show_bug.cgi?id=4421 --- Comment #59 from Chad H. 2010-04-02 15:37:08 UTC --- (In reply to comment #56) > Helps with what? Realizing you have to upload a replacement image to another > name because this bug isn't closed? For what other reason would it matter > what > format the file is? (even though you'd be able to tell regardless) You still haven't explained how we're supposed to know what [[File:Name]] is when looking at the syntax. (In reply to comment #58) > The only thing this feature does (if enabled) is *allow* for the creation of > "http://commons.wikimedia.org/wiki/File:Banana";, and decouple the MIME type > from the page title extension. It does not automatically strip off the > extension from existing page titles or create automatic redirects of any sort. > The question is not "will it break existing images," it's that when you strip the extension, the name becomes meaningless. If I'm trying to include a picture of a Banana, I want a JPG or PNG, not a MPG. What type of media am I using here [[File:Banana]]? By keeping the extension, it's not (as) ambiguous. Like Roan said above, it's not a magic bullet, but it certainly helps. > The parenthetical "(if enabled)" bit is important here, too. There's nothing > forcing anyone (including Wikimedia Foundation) to actually use this feature > just by virtue of MediaWiki supporting the functionality. Yes, but if it's not a good feature (which we seem to disagree on), we shouldn't support it at all. If we implemented every idea someone had, we'd have a lot less WONTFIXes. I think the outstanding questions need answering, before this moves forward any more. -- 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 4421] Image file extension should not be part of the name
https://bugzilla.wikimedia.org/show_bug.cgi?id=4421 --- Comment #58 from Rob Lanphier (RobLa) 2010-04-02 15:25:29 UTC --- > So what would this do for cases like > http://commons.wikimedia.org/wiki/File:Banana.JPG and > http://commons.wikimedia.org/wiki/File:Banana.png? The two are of completely > different images. Since they have two different page titles, they'd be treated as two different images. For that matter, http://commons.wikimedia.org/wiki/File:Banana.jpeg and http://commons.wikimedia.org/wiki/File:Banana.jpg would still be treated as two different images. The only thing this feature does (if enabled) is *allow* for the creation of "http://commons.wikimedia.org/wiki/File:Banana";, and decouple the MIME type from the page title extension. It does not automatically strip off the extension from existing page titles or create automatic redirects of any sort. The parenthetical "(if enabled)" bit is important here, too. There's nothing forcing anyone (including Wikimedia Foundation) to actually use this feature just by virtue of MediaWiki supporting the functionality. -- 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 23028] Upload form doen't work with non-latin filenames
https://bugzilla.wikimedia.org/show_bug.cgi?id=23028 yakoff changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE | --- Comment #2 from yakoff 2010-04-02 15:09:35 UTC --- I don't think it is a duplicate of bug 1780.. The problem affects the Special:UploadWindow and the way it returns the filename to the form. When Special:UploadWindow closes and passes the filename to the main form the string gets corrupted and instead of "Файл.jpg" it appears as "Файл.jpg" But the uploading itself is fine. File is uploaded and can be found with correct name. -- 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 4421] Image file extension should not be part of the name
https://bugzilla.wikimedia.org/show_bug.cgi?id=4421 NuclearWarfare changed: What|Removed |Added CC||nw.wikipe...@gmail.com --- Comment #57 from NuclearWarfare 2010-04-02 15:02:09 UTC --- So what would this do for cases like http://commons.wikimedia.org/wiki/File:Banana.JPG and http://commons.wikimedia.org/wiki/File:Banana.png? The two are of completely different images. -- 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 1780] Can't upload file with non-ASCII name (eg cyrillic) on Windows host
https://bugzilla.wikimedia.org/show_bug.cgi?id=1780 Chad H. changed: What|Removed |Added CC||yak...@yakoff.ru --- Comment #20 from Chad H. 2010-04-02 14:58:46 UTC --- *** Bug 23028 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 23028] Upload form doen't work with non-latin filenames
https://bugzilla.wikimedia.org/show_bug.cgi?id=23028 Chad H. changed: What|Removed |Added Status|NEW |RESOLVED CC||innocentkil...@gmail.com Resolution||DUPLICATE --- Comment #1 from Chad H. 2010-04-02 14:58:46 UTC --- *** This bug has been marked as a duplicate of bug 1780 *** -- 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 23028] New: Upload form doen't work with non-latin filenames
https://bugzilla.wikimedia.org/show_bug.cgi?id=23028 Summary: Upload form doen't work with non-latin filenames Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: critical Priority: Normal Component: SemanticForms AssignedTo: yaro...@gmail.com ReportedBy: yak...@yakoff.ru CC: wikibugs-l@lists.wikimedia.org When uploading file with non-latin characters in its name (e.g. russian), the file is uploaded, but the filename substituted in the corresponding field of the main form gets corrupted (looks like broken utf). This is true for MSIE, while in Chrome everything works fine. Tested it both on my own installation and on http://discoursedb.org/wiki/Form:Images_test -- 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 19540] cannot add comments to techblog.wikimedia.org from certain IP ranges
https://bugzilla.wikimedia.org/show_bug.cgi?id=19540 MZMcBride changed: What|Removed |Added CC||b...@mzmcbride.com --- Comment #13 from MZMcBride 2010-04-02 14:55:04 UTC --- Is there some measure of the effectiveness or usefulness of these blacklists? -- 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 4421] Image file extension should not be part of the name
https://bugzilla.wikimedia.org/show_bug.cgi?id=4421 --- Comment #56 from reisio 2010-04-02 14:45:59 UTC --- Helps with what? Realizing you have to upload a replacement image to another name because this bug isn't closed? For what other reason would it matter what format the file is? (even though you'd be able to tell regardless) -- 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 21622] loading a wikipedia article crashes my browser
https://bugzilla.wikimedia.org/show_bug.cgi?id=21622 --- Comment #9 from John Doe 2010-04-02 13:20:44 UTC --- I don't think it was solely the fundraising banners. Shortly after they were gone, Mozilla 1.7.2 still crashed with javascript enabled. Eventually the problem went away, so I figured the source of the problem had been found, but there were no updates to this thread at the time. Long before the Wiki problem, Google maps would crash it too. Started right after some Win XP updates, and still persists. -- 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 23007] Edit Field text: "Briefly decribe..." miss positioned
https://bugzilla.wikimedia.org/show_bug.cgi?id=23007 --- Comment #3 from hannes 2010-04-02 13:20:26 UTC --- Created an attachment (id=7260) --> (https://bugzilla.wikimedia.org/attachment.cgi?id=7260) justification error on FF3.0 -- 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 23007] Edit Field text: "Briefly decribe..." miss positioned
https://bugzilla.wikimedia.org/show_bug.cgi?id=23007 --- Comment #2 from hannes 2010-04-02 13:19:31 UTC --- This seem to occure on FF3.0 as well. See Screenshot -- 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 19540] cannot add comments to techblog.wikimedia.org from certain IP ranges
https://bugzilla.wikimedia.org/show_bug.cgi?id=19540 --- Comment #12 from jida...@jidanni.org 2010-04-02 13:12:35 UTC --- OK, I logged in and submitted a comment again. Same block message. Yes http://www.dnsqueries.com/en/check_banned_ip.php shows the same dynamic IP range etc. for 218.163.8.76 which I am using today as you can see too. -- 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 23023] Admin shortcuts are not working in Vector
https://bugzilla.wikimedia.org/show_bug.cgi?id=23023 Calcey QA changed: What|Removed |Added CC||wikib...@calcey.com --- Comment #4 from Calcey QA 2010-04-02 12:23:09 UTC --- IE 7 and 8 fail on below functions - My user page - Edit box -- 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 4421] Image file extension should not be part of the name
https://bugzilla.wikimedia.org/show_bug.cgi?id=4421 --- Comment #55 from Roan Kattouw 2010-04-02 12:19:00 UTC --- (In reply to comment #54) > How does one know the difference between a GIF and an animated GIF based on > file extension? How does one know the difference between a Flash file (.swf) > that just has static vector art versus video? How does one know the > difference > between a static .svg and one that includes a element? > Sure, a file's extension is not a magic bullet that unambiguously tells you everything you want to know about a file. But it *helps* a great deal. -- 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 21215] NoLocalSettings.php doesn't tolerate rewrite rules
https://bugzilla.wikimedia.org/show_bug.cgi?id=21215 Chad H. changed: What|Removed |Added CC||innocentkil...@gmail.com --- Comment #10 from Chad H. 2010-04-02 12:17:56 UTC --- (In reply to comment #0) > If you visit a not installed wiki not via script path (http://example.com/w/), > but via path created by rewrite rules (http://example.com/wiki/), you will see > that the usual "Please set up the wiki first" message fails to display the > MediaWiki logo because its relative URL is > /wiki/skins/common/images/mediawiki.png. Ugh, that's because we don't know the real script path yet...we've gotten here via rewrite rules and $wgScriptPath is useless. > Probably, just link to the mw.org one? That's one solution. Only other way I can think of would be getting the dirname and trying to guess. But that's very likely to fail. -- 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 23027] Abuse filter does not allow for use of old_text or old_html
https://bugzilla.wikimedia.org/show_bug.cgi?id=23027 --- Comment #1 from Andrew Garrett 2010-04-02 11:42:21 UTC --- They are deliberately disabled for performance reasons. Some engineering would be required to bring them to a state where they would not bring the site down. -- 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 23027] New: Abuse filter does not allow for use of old_text or old_html
https://bugzilla.wikimedia.org/show_bug.cgi?id=23027 Summary: Abuse filter does not allow for use of old_text or old_html Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: major Priority: Normal Component: AbuseFilter AssignedTo: agarr...@wikimedia.org ReportedBy: delbu...@my.erau.edu CC: wikibugs-l@lists.wikimedia.org In the details of the abuse filter log -- such as http://test.wikipedia.org/w/index.php?title=Special:AbuseLog&details=1784 -- one can clearly see the presence of the old_text and old_html variables. These variables are clearly documented at http://www.mediawiki.org/wiki/Extension:AbuseFilter/RulesFormat However attempting to use these variables in a filter results in a syntax error for unknown variables: "abc" in old_text results in Syntax error detected: Unrecognised variable old_text at character 8 new_text and new_html work fine. This is a problem because to use new_text or new_html, a proper filter often needs to also check old_text or old_html, respectively. Enwiki in particular is dealing with a particular vandal against whom new_text is the only appropriate choice, but without old_text this filter is encountering false positives. Looking at the source code, old_text and old_html already appear to be implemented, it just seems that old_text and old_html are just not recognized by the abuse filter parser for some reason. -- 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 22867] create protected shared filepage has view-source tab
https://bugzilla.wikimedia.org/show_bug.cgi?id=22867 Alexandre Emsenhuber [IAlex] changed: What|Removed |Added Status|NEW |RESOLVED CC||alex.emsenhu...@bluewin.ch Resolution||FIXED --- Comment #1 from Alexandre Emsenhuber [IAlex] 2010-04-02 08:01:12 UTC --- Fixed in r64517. -- 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 23024] Special:ListFiles doesn't escape filenames
https://bugzilla.wikimedia.org/show_bug.cgi?id=23024 Alexandre Emsenhuber [IAlex] changed: What|Removed |Added Status|NEW |RESOLVED CC||alex.emsenhu...@bluewin.ch Resolution||FIXED --- Comment #2 from Alexandre Emsenhuber [IAlex] 2010-04-02 07:09:38 UTC --- Fixed in r64516. -- 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
