[Bug 19166] Review-API-Module is not working on WMF-Projects
https://bugzilla.wikimedia.org/show_bug.cgi?id=19166 --- Comment #3 from P.Copp 2009-06-12 06:28:39 UTC --- Created an attachment (id=6220) --> (https://bugzilla.wikimedia.org/attachment.cgi?id=6220) Update extension to match new interface of ApiMain::isWriteMode() -- 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 19166] Review-API-Module is not working on WMF-Projects
https://bugzilla.wikimedia.org/show_bug.cgi?id=19166 --- Comment #2 from P.Copp 2009-06-12 06:25:29 UTC --- There was an interface change in ApiMain.php wrt. to requesting write mode. However, I think the problem has already been fixed in trunk with r50833. -- 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 18173] Login form barfs on malformed REMOTE_ADDR
https://bugzilla.wikimedia.org/show_bug.cgi?id=18173 ^demon changed: What|Removed |Added Resolution|FIXED |WONTFIX --- Comment #11 from ^demon 2009-06-12 02:25:58 UTC --- Reverted in r51774. Faking IPs is bad. Instead, we'll try to get the IP as best as possible from REMOTE_ADDR or HTTP_X_FORWARDED_FOR. Barring that, we cannot proceed without an IP address. An exception is now thrown if the IP cannot be determined. -- 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 8867] Hook to alter upload form
https://bugzilla.wikimedia.org/show_bug.cgi?id=8867 --- Comment #6 from Michael Dale 2009-06-12 02:03:06 UTC --- hmm... I think its fine... but you have to send me a diff since my SpecialUpload.php is pretty different from the turnk you can generate a patch against new-upload branch ( /branches/new-upload/phase3 ) I will plop it in there. -- 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 19030] in FF 3.5b4 timer shows full time of original clip
https://bugzilla.wikimedia.org/show_bug.cgi?id=19030 Michael Dale changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #2 from Michael Dale 2009-06-12 01:32:27 UTC --- I think we ~want~ to show the time of the original clip since it just gets too darn confusing to try and do seeking and things (presently) when we throw away the offset info. In the future oggz-chop will rewrite the timecodes and we won't have this problem. -- 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 18563] Merge new-upload branch (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=18563 --- Comment #6 from Michael Dale 2009-06-12 01:26:38 UTC --- ran a merge to head in r51762 things are working better on all around ... I would attach a "patch" but it will be pretty monstrous plus there are a lot of images involved. I think I will do a ~test~ commit to trunk soon... -- 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 18173] Login form barfs on malformed REMOTE_ADDR
https://bugzilla.wikimedia.org/show_bug.cgi?id=18173 Aryeh Gregor changed: What|Removed |Added CC||simetrical+wikib...@gmail.co ||m 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 19168] New: is broken inside tags
https://bugzilla.wikimedia.org/show_bug.cgi?id=19168 Web browser: --- Summary: is broken inside tags Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: Normal Component: Templates AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: snottygob...@gmail.com does not work within tags. Create a page with content AB Then transclude it into another page. One would expect the transcluded page to contain the "B", but it does not. I'm ranking this normal rather than minor because the problem is blocking effective footnote overflow handling at the English Wikisource. -- 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 19167] Can not print out a PDF file of enwiki article Uniforms of the United States Marine Corps
https://bugzilla.wikimedia.org/show_bug.cgi?id=19167 p858snake changed: What|Removed |Added CC||p858sn...@yahoo.com.au Severity|major |normal Web browser|Mozilla Firefox 3.0.x |--- Component|wikibugs|General/Unknown Keywords|bugday | OS/Version|Windows Vista |All Platform|PC |All --- Comment #1 from p858snake 2009-06-12 00:23:09 UTC --- Changed Component: Wikibugs → General/Unknown (Wikibugs is for the irc spamming script) Changed Keywords: Bugday → [NONE] (Not accepted into a bugday and they havn't been run for awhile) Changed Web Browser: Mozilla Firefox 3.0.X → [NONE] (This doesn't appears to be a browser indepent issue) Changed Hardware: PC → All (This doesn't appears to be a hardware indepent issue) Changed OS: Windows Vista → All (This doesn't appears to be a operating system indepent issue) -- 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 19166] Review-API-Module is not working on WMF-Projects
https://bugzilla.wikimedia.org/show_bug.cgi?id=19166 --- Comment #1 from Aaron Schulz 2009-06-12 00:17:32 UTC --- how long has this been the case? -- 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 19167] New: Can not print out a PDF file of enwiki article Uniforms of the United States Marine Corps
https://bugzilla.wikimedia.org/show_bug.cgi?id=19167 Web browser: Mozilla Firefox 3.0.x Summary: Can not print out a PDF file of enwiki article Uniforms of the United States Marine Corps Product: Wikimedia Version: unspecified Platform: PC OS/Version: Windows Vista Status: NEW Keywords: bugday Severity: major Priority: Normal Component: wikibugs AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: glacierw...@yourwiki.net Created an attachment (id=6219) --> (https://bugzilla.wikimedia.org/attachment.cgi?id=6219) Screen shot of PDF Error on Uniforms of the United States Marine Corps article on enwiki Here's the error message word for word: POST request failed >From Wikipedia, the free encyclopedia Jump to: navigation, search The POST request to http://pdf1.wikimedia.org:8080/mw-serve/ failed (Operation timed out after 3000 milliseconds with 0 bytes received). Return to Main Page. Apparently, I'm not alone: There were postings to Wikipedia Help Desk [http://en.wikipedia.org/wiki/Wikipedia:Hd#PDF_won.27t_appear] and Village Pump (technical) [http://en.wikipedia.org/wiki/Wikipedia:VPT#.22PDF_version.22_option_not_working] It also seems that other wikis are having the same issue. -- 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 19004] API: support for "tags"
https://bugzilla.wikimedia.org/show_bug.cgi?id=19004 Gurch changed: What|Removed |Added Priority|Normal |High --- Comment #1 from Gurch 2009-06-12 00:07:40 UTC --- Bumping priority on this to High since it would also serve as a partial workaround for the Abuse Filter's complete workflow breakage that is bug 18374, which is sorely needed for recent changes patrolling. -- 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 18829] Add border="1" to tables, not just their stylesheets
https://bugzilla.wikimedia.org/show_bug.cgi?id=18829
--- Comment #17 from Happy-melon 2009-06-12 00:00:28
UTC ---
(In reply to comment #16)
> OK, I've traced Pager.php's $s = " "TablePager_nav a { text-decoration: none; }", meaning that all
> browsers including text browsers should see a default of border="0".
> So Pager.php doesn't need any fixing, although explicitly saying
> wouldn't hurt.
>
I thought the issue was that, without stylesheets, text browers *didn't*
display borders when they *should* do?? Won't "a default of border='0'" result
in no cell borders on text browsers? Am I misunderstanding?
--
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 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161
--- Comment #6 from Platonides 2009-06-11 22:33:46 UTC
---
The site http://austinhair.org/guess/ is a good example in-the-wild.
It has been promoted in mailing lists, irc, looks like a funny app and sends
you
to rarely used wikis with the user knowing about it. If the site operator
decides
to correlate the logs, he will get lots of wikimedian ips.
(In reply to comment #4)
> I am not very well versed in web security, but from what I have found with a
> search engine, there existed exploits in the past for browsers as well as
> media
> plugins to redirect users to websites with a fake referer. The general opinion
> seems to be that it is not good security practice to rely on the referer not
> being tampered with.
{{reference-needed}}
An evil guy can easily use a fake referer, but a legitimate user would provide
the
right one (or none at all). It could be bypassed with things like clickjacking,
though.
(In reply to comment #5)
> Malicious remote websites could still force visitors to POST to Wikimedia. A
> simple with someformelement.click() would do nicely.
It'd obviously also use a token.
--
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 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 --- Comment #5 from Splarka 2009-06-11 22:31:46 UTC --- (In reply to comment #4) > From a purely philosophical position, database changes (such as account > creation) resulting from a HTTP GET seem to go against the spirit of RFC 1945, > where the POST method was specifically created for such purposes. Malicious remote websites could still force visitors to POST to Wikimedia. A simple with someformelement.click() would do nicely. Also, bug 19006 can be a similar scenario perpetrated locally. Eg: http://www.mediawiki.org/wiki/Special:ExpandTemplates?input=%5Bhttp%3A%2F%2Fsome.dirty.website%2F%3Fuser%3D%7B%7Burlencode%3A%7B%7BREVISIONUSER%7D%7D%7D%7D+some+citation%5D -- 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 19148] SmoothGallery: Call to a member function getText() on a non-object
https://bugzilla.wikimedia.org/show_bug.cgi?id=19148 ^demon changed: What|Removed |Added CC||innocentkil...@gmail.com Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from ^demon 2009-06-11 22:28:48 UTC --- Fixed in r51766. -- 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 14201] Create AdminSettings.php during wiki installation, in the same way as LocalSettings.php
https://bugzilla.wikimedia.org/show_bug.cgi?id=14201 Bug 14201 depends on bug 18768, which changed state. Bug 18768 Summary: Remove AdminSettings.php from MediaWiki core https://bugzilla.wikimedia.org/show_bug.cgi?id=18768 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 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 16322] Allow maint scripts to accept DB user/pass over input or params if no AdminSettings.php
https://bugzilla.wikimedia.org/show_bug.cgi?id=16322 Bug 16322 depends on bug 18768, which changed state. Bug 18768 Summary: Remove AdminSettings.php from MediaWiki core https://bugzilla.wikimedia.org/show_bug.cgi?id=18768 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 18768] Remove AdminSettings.php from MediaWiki core
https://bugzilla.wikimedia.org/show_bug.cgi?id=18768 ^demon changed: What|Removed |Added CC||innocentkil...@gmail.com Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #2 from ^demon 2009-06-11 22:21:52 UTC --- No, only the requirement for update.php. commandLine.inc still expects AdminSettings to be there. Will be fixed with merge of maintenance-work branch. -- 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 14201] Create AdminSettings.php during wiki installation, in the same way as LocalSettings.php
https://bugzilla.wikimedia.org/show_bug.cgi?id=14201 Bug 14201 depends on bug 18768, which changed state. Bug 18768 Summary: Remove AdminSettings.php from MediaWiki core https://bugzilla.wikimedia.org/show_bug.cgi?id=18768 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 16322] Allow maint scripts to accept DB user/pass over input or params if no AdminSettings.php
https://bugzilla.wikimedia.org/show_bug.cgi?id=16322 Bug 16322 depends on bug 18768, which changed state. Bug 18768 Summary: Remove AdminSettings.php from MediaWiki core https://bugzilla.wikimedia.org/show_bug.cgi?id=18768 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 18768] Remove AdminSettings.php from MediaWiki core
https://bugzilla.wikimedia.org/show_bug.cgi?id=18768 MZMcBride changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from MZMcBride 2009-06-11 22:17:26 UTC --- I believe Tim resolved this in rev 51650. Resolving as 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 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 x127 changed: What|Removed |Added CC||x...@nic-nac-project.de --- Comment #4 from x127 2009-06-11 22:15:13 UTC --- As it seems there is no wish for secrecy, let me discuss this attack in the open. (Most can be infered from the comments so far, anyway) Basically, an external website could redirect wikimedia users to any of the smaller wikimedia projects where they will likely not have an account yet. This might happen in a hidden frame without the user noticing anything at all. Then, the external website would correlate the timestamps of the account creation log from the smaller wikimedia project with its web server log to obtain a mapping of IP addresses and usernames. This attack assumes that it is possible to lure many wikimedia users to an external site. I can think of two ways to do that. The obvious way would be to add the external URL as a source or citation for various articles. If the attacker does not mind violating the copyrights of third parties, the linked content may even appear relevant. This form of attack would mostly target wikipedian who watch the recent changes to fight vandalism. Another way to do it would be to use a website already in place. There may be websites out there which are openly hostile to some wikimedia projects and interested in figuring out the identity of senior editors. Furthermore, it is possible that some of the senior editors already monitor these websites, so there may not even be a need to lure them there. (Note: all of these assumptions are speculative from what I have read years ago on /. or something.) As others have remarked, there are other ways to determine the IP address of editors. One could put external links on their talk pages or send them via IRC, or one could mail them mails containing web bugs. All these methods target users specifically and scale badly. The attack described above, on the other hand, scales well. There are probably numerous wikimedia projects with a low account creation rate, and to each of them there could be a redirect every few seconds with the time correlation between the logs being maintained. In practice, the attack speed would only be limited by the number of wikimedia users visiting the external website. Assuming attackers are able to lure a significant percentage of the community to their site, I would call the impact of this attack an "unofficial checkuser database". Disabling account creation from external referers would certainly complicate the attack. One might try to trick people into clicking an internal link on a wikimedia page loaded in a frame. This would greatly decrease the time correlation, making it more difficult to match users. Also, users would probably have to realize that they are browsing a wikimedia site and some may not click on the desired link. I am not very well versed in web security, but from what I have found with a search engine, there existed exploits in the past for browsers as well as media plugins to redirect users to websites with a fake referer. The general opinion seems to be that it is not good security practice to rely on the referer not being tampered with. >From a purely philosophical position, database changes (such as account creation) resulting from a HTTP GET seem to go against the spirit of RFC 1945, where the POST method was specifically created for such purposes. In conclusion, I would call into question whether automatic account creation is a overall good thing from a user point of view. If instead of automatically creating a user account upon detection of cookie information, one would simply put a button (so that on could utilize the POST method) on the page called "create account for $USER", the overall usability would not decrease that much. After all, most users do not spend that much time visiting projects they never visited before. -- 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 19148] SmoothGallery: Call to a member function getText() on a non-object
https://bugzilla.wikimedia.org/show_bug.cgi?id=19148
--- Comment #1 from Gregor Hagedorn 2009-06-11
22:03:20 UTC ---
Update: The error is probably not related to 1.16, but to using a shared
repository.
If no image description is provided, ''and'' the image comes from a shared
repository that uses API connection (such as using images from Wikimedia
Commons), then the following code in SmoothGalleryParser fails with a fatal
error:
if ( $description == '' ) {
// Load the image page from the database with the provided title from the
image object
$db = wfGetDB( DB_SLAVE );
$img_rev = Revision::loadFromTitle( $db, $title );
// Get the text from the image page's description
$description = $img_rev->getText();
}
--
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 19061] English Wikinews as an external file repository for Serbian Wikinews
https://bugzilla.wikimedia.org/show_bug.cgi?id=19061 Steve Sanbeg changed: What|Removed |Added Keywords||shell -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19166] New: Review-API-Module is not working on WMF-Projects
https://bugzilla.wikimedia.org/show_bug.cgi?id=19166 Web browser: --- Summary: Review-API-Module is not working on WMF-Projects Product: MediaWiki extensions Version: any Platform: All URL: http://de.wikipedia.org/w/api.php?action=review&token=XX &60921947&flag_accuracy=1 OS/Version: All Status: NEW Severity: major Priority: Normal Component: FlaggedRevs AssignedTo: jschulz_4...@msn.com ReportedBy: bugrepor...@to.mabomuja.de flagging or unflagging a revision does not work on wmf-projects as described on api.php. The server always return a "500 Internal Server Error" -- 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 19165] New: Pick a single head tag for the Universal Edit Button
https://bugzilla.wikimedia.org/show_bug.cgi?id=19165 Web browser: --- Summary: Pick a single head tag for the Universal Edit Button Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: minor Priority: Normal Component: Page rendering AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: greenrea...@hotmail.com The Universal Edit Button code originally added a meta tag similar to the following: A suggestion on the discussion page of the Universal Edit Button website (http://universaleditbutton.org/Talk:Add_The_Link#Linking_Scheme) led to the implementation of a duplicate meta tag to provide the same functionality in r42339, looking something like this: As $wgUniversalEditButton is on by default, these tags combined take up over 500 bytes in the head of every page rendered by MediaWiki when you have longer, non-English URLs like /w/index.php?title=%D0%92%D0%B8%D0%BA%D0%B8%D0%A4%D1%83%D1%80:%D0%98%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D1%8B%D0%B9_%D0%A4%D1%83%D1%80%D1%80%D0%B8-%D0%BF%D0%BE%D1%80%D1%82%D0%B0%D0%BB&action=edit. While the use of rel="edit" may actually be cleaner, the fact is it is even less of a standard than that supported by the Firefox plugin. If we're going to have one, it would be better to just pick one. -- 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 19162] rel="license" on link should replace copyright meta tag
https://bugzilla.wikimedia.org/show_bug.cgi?id=19162 --- Comment #1 from Laurence 'GreenReaper' Parry 2009-06-11 18:09:47 UTC --- Created an attachment (id=6218) --> (https://bugzilla.wikimedia.org/attachment.cgi?id=6218) Removes copyright meta tag, adds rel="license" to 'copyright' footer link -- 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 19157] createAndPromote error on bad password
https://bugzilla.wikimedia.org/show_bug.cgi?id=19157 --- Comment #1 from emufarm...@gmail.com 2009-06-11 18:07:39 UTC --- Created an attachment (id=6217) --> (https://bugzilla.wikimedia.org/attachment.cgi?id=6217) Adds password checking; also makes the other messages a little more informative -- 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 19164] New: SQL error 1071 when running update script
https://bugzilla.wikimedia.org/show_bug.cgi?id=19164 Web browser: --- Summary: SQL error 1071 when running update script Product: MediaWiki Version: 1.15.0 Platform: All OS/Version: All Status: NEW Severity: normal Priority: Normal Component: Database AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: omega...@yahoo.com Created an attachment (id=6216) --> (https://bugzilla.wikimedia.org/attachment.cgi?id=6216) Screen shot of the error When I tried to run the upgrade script I got, after an alert the script tried to increase memory_limit to above the allowed limit, something about REMOTE_ADDR not being set, and an unexpected REMOTE_USER authentication failure, an SQL error 1071 when creating the table fedtrek_wiki_spoofuser. Attached is a screen shot of the error. If it helps, the server the wiki is on runs CentOS 5, MySQL 5.1.35, and PHP 5.2.9 with Suhosin-patch 0.9.7, APD 1.0.1, XDebug 2.0.4, and Sushosin 0.9.27. -- 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 19163] New: Special:GlobalBlock/127.0.0.1 should load global block log snippet
https://bugzilla.wikimedia.org/show_bug.cgi?id=19163 Web browser: --- Summary: Special:GlobalBlock/127.0.0.1 should load global block log snippet Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: normal Priority: Normal Component: GlobalBlocking AssignedTo: agarr...@wikimedia.org ReportedBy: mike.lifegu...@gmail.com Please load recent relevant log entries here just like on the local block form. -- 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 19162] New: rel="license" on link should replace copyright meta tag
https://bugzilla.wikimedia.org/show_bug.cgi?id=19162 Web browser: --- Summary: rel="license" on link should replace copyright meta tag Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: User interface AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: greenrea...@hotmail.com Search engines use the rel="license" tag to determine whether content is licensed freely (see http://tantek.com/presentations/2006/09/microformats-intro/ ). We already have this link in the page footer, we're just not tagging it with the rel. We should. Conversely, the use of the "copyright" meta tag is inappropriate (a license isn't a copyright), and essentially a waste of space on every page served by MediaWiki, as it does not appear to be used in the same way. We should remove 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 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 Andrew Garrett changed: What|Removed |Added CC||agarr...@wikimedia.org --- Comment #3 from Andrew Garrett 2009-06-11 17:38:09 UTC --- The exact scenario is described in the non-public OTRS wiki: http://otrs-wiki.wikimedia.org/wiki/User:Church_of_emacs/mw_critical_bug That's pretty useless, then. -- 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 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 --- Comment #2 from church.of.emacs...@gmail.com 2009-06-11 17:37:05 UTC --- > Disabling account creation if there's an external referer would drop this > concern. I'm not so sure about that. What if there is no referer (e.g. link in IRC)? Also, this is confusing for the user: sometimes accounts are created automatically, and sometimes not. What if the user gets both the link to evilserver and the wiki page? Presumably he clicks on both of them in a short space of time, which would mean the same kind of vulnerability. IMHO the best way of fixing this (and the only way that is completely secure) is to disable the 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 19107] Tag filter for Oldreviewedpages
https://bugzilla.wikimedia.org/show_bug.cgi?id=19107 --- Comment #3 from cenarium.sy...@gmail.com 2009-06-11 17:11:29 UTC --- I think it would be more used in order to review tagged edits than as a filter for oldreviewedpages, so we could use another special page without problem, yes. To make it visible enough to users though, it would have to be linked from [[Special:Tags]] similarly to the tagged changes, maybe a (review) link for users with review permission. There shouldn't be any strong need for the namespace, category, max change bytes or 'on my watchlist' filter. And the only interesting level would be 'sighted' for the default (and 'patrol' for the English Wikipedia implementation). So there's only a need for the tag filter in the end. -- 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 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 Platonides changed: What|Removed |Added CC||platoni...@gmail.com --- Comment #1 from Platonides 2009-06-11 17:08:31 UTC --- You'd still need to send it to a logged wiki user. Note that if done via irc, just accessing the evil server can be correlated with the irc user (which is usually correlated with the wiki account). If you know the email, you are likely to know the account. You can append a token to the url you make them visit. Where it would be most useful would be when the evil link is at one wiki. Disabling account creation if there's an external referer would drop this concern. Having the user click a link to activate their account there seems sensible, though. -- 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 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 church.of.emacs...@gmail.com changed: What|Removed |Added CC||church.of.emacs...@gmail.com Priority|Normal |High -- 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 19161] New: Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 Web browser: --- Summary: Auto account creation creates privacy vulnerability Product: MediaWiki extensions Version: any Platform: All URL: http://otrs- wiki.wikimedia.org/wiki/User:Church_of_emacs/mw_critical _bug OS/Version: All Status: NEW Severity: critical Priority: Normal Component: CentralAuth AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: church.of.emacs...@gmail.com The exact scenario is described in the non-public OTRS wiki: http://otrs-wiki.wikimedia.org/wiki/User:Church_of_emacs/mw_critical_bug I remember having a discussion with Tim Starling and Brion Vibber when Wikimedia began to automatically create accounts on normal GET-requests. Tim and I had some concerns, while Brion rightfully said that the information of user:abc visiting a Wikipedia version on a specific date was a minor privacy concern. However, in the scenario (see URL) it seemed like this feature could lead to much more private information leaking. Therefore I propose to disable automatic account creation on GET-requests and instead use only POST-requests to create accounts. -- 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 19160] New: DISTINCTROW with Postgres
https://bugzilla.wikimedia.org/show_bug.cgi?id=19160 Web browser: Mozilla Firefox 3.0.x Summary: DISTINCTROW with Postgres Product: MediaWiki Version: 1.15.0 Platform: All OS/Version: All Status: NEW Keywords: postgresql Severity: minor Priority: Normal Component: Database AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: mguerr...@gmail.com When trying to execute one of the maintenance scripts, it fails because it was sending a query with the reserved word "DISTINCTROW" to the Postgres database server of my installation. Postgres does not support this word. The scrip: /maintenance$ php deleteOldRevisions.php --delete 76 The error is on the query: SELECT DISTINCTROW rev_text_id FROM revision The workaround: Edit the file purgeOldText.inc, in the lines 23 and 31, replacing the text "DISTINCTROW" with "DISTINCT" Tip: Doing a little search it appears that "DISTINCTROW" is not standard SQL. I suggest replacing all references to "DISTINCTROW" to "DISTINCT" in futures releases of MediaWiki. -- 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 18612] Please enable transwiki import and upload import to es.wikibooks.
https://bugzilla.wikimedia.org/show_bug.cgi?id=18612 Rob Halsell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Rob Halsell 2009-06-11 15:39:16 UTC --- The list can certainly be changed in the future, no worries! I have added the import sources you requested. If you need further ones, just enter a new ticket =] -- 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 19158] Logged in as another user
https://bugzilla.wikimedia.org/show_bug.cgi?id=19158 Platonides changed: What|Removed |Added CC||platoni...@gmail.com --- Comment #2 from Platonides 2009-06-11 15:27:01 UTC --- Yes, they could be session collisions. See bug 6464 for a previous instance of this bug. A username check like r42040 on CentralAuthUser::getSession() seems a good idea. -- 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 14731] Wiki for Wikimedia Russia
https://bugzilla.wikimedia.org/show_bug.cgi?id=14731 Rob Halsell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Rob Halsell 2009-06-11 14:45:41 UTC --- I was able to pull DNS from elsewhere. The wiki is now online and ready for you guys to start changing it. -- 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 19159] New: \overleftrightarrow incorrectly parsed
https://bugzilla.wikimedia.org/show_bug.cgi?id=19159
Web browser: Mozilla Firefox 3.0.x
Summary: \overleftrightarrow incorrectly parsed
Product: MediaWiki extensions
Version: any
Platform: All
URL: http://www.mediawiki.org/wiki/Manual:Enable_TeX/problems
#overleftrightarrow
OS/Version: All
Status: NEW
Severity: normal
Priority: Normal
Component: texvc
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: joshua...@gmail.com
The overleftrightarrow is an ams-math function. However, Texvc treats it like
it is a TeX function.
For example, \overleftrightarrow{AB} will throw the error " Failed
to parse (PNG conversion failed; check for correct installation of latex,
dvips, gs, and convert): \overleftrightarrow{A B}
Whereas, \mathit{i}\overleftrightarrow{AB} works.
I believe that the parser/tokenizer just needs to specify amsmath when it comes
across \overleftrightarrow in the code. My workaround right now is dumb, such
that I just force ams-math to be used in all latex processing.
--
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 14731] Wiki for Wikimedia Russia
https://bugzilla.wikimedia.org/show_bug.cgi?id=14731 --- Comment #2 from Rob Halsell 2009-06-11 14:42:30 UTC --- I have added the wiki and the settings. I also added DNS, however, I have negative DNS caching on my end due to pulling the page before it was done. I need to let it expire and I will finish this 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 19158] Logged in as another user
https://bugzilla.wikimedia.org/show_bug.cgi?id=19158 Andrew Garrett changed: What|Removed |Added CC||agarr...@wikimedia.org Severity|critical|major Summary|CentralAuth only looks for |Logged in as another user |Session-Cookie? | --- Comment #1 from Andrew Garrett 2009-06-11 14:41:38 UTC --- Changing bug summary from speculation to observation, downgrading severity because it's very infrequent. -- 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 19158] New: CentralAuth only looks for Session-Cookie?
https://bugzilla.wikimedia.org/show_bug.cgi?id=19158 Web browser: --- Summary: CentralAuth only looks for Session-Cookie? Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: critical Priority: Normal Component: CentralAuth AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: ap...@apper.de Hi, at de.wikipedia someone who seems reliable (8k edits) claims, that he was identified as a wrong user - he could do everything from this user (he posted a screenshot from the Settings (see http://de.wikipedia.org/wiki/Datei:Alasto2.png). His username is Marsupilami, the occupied username is Alasto2. His cookies are correct (see http://de.wikipedia.org/w/index.php?title=Wikipedia:Fragen_zur_Wikipedia&oldid=61039969#Wieso_bin_ich_nicht_mehr_ich.3F at the bottom). After having a quick look at CentralAuthUser.php it seems to me, that getSession() only looks after the MD5 hash in the Session cookie. So maybe it's unlikly, that two people have the same hash, but I think it would be better to also check the "centralauth_User" cookie. I'm not sure, if I see the code correctly, but there is the problem, that one user can see/do everything for another user. -- 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 19133] Maintenance script cleanup
https://bugzilla.wikimedia.org/show_bug.cgi?id=19133 ^demon changed: What|Removed |Added Depends on||19157 -- 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 19157] New: createAndPromote error on bad password
https://bugzilla.wikimedia.org/show_bug.cgi?id=19157 Web browser: --- Summary: createAndPromote error on bad password Product: MediaWiki Version: 1.16-svn Platform: All OS/Version: All Status: NEW Severity: normal Priority: Normal Component: Maintenance scripts AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: innocentkil...@gmail.com Blocks: 19133 If createAndPromote is fed a bad password, the account is created anyway. Should roll back the creation if we can't make a valid PW. -- 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 18612] Please enable transwiki import and upload import to es.wikibooks.
https://bugzilla.wikimedia.org/show_bug.cgi?id=18612 --- Comment #5 from Dferg 2009-06-11 11:28:20 UTC --- (In reply to comment #4) > What sources do you want to be able to import from? > At first, es.wikipedia.org, en.wikipedia.org, meta and en.wikibooks.org if possible. Can this list be modified in the future?. 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 9119] Improper base font size
https://bugzilla.wikimedia.org/show_bug.cgi?id=9119 Siebrand changed: What|Removed |Added CC||siebr...@wikipedia.be Keywords||need-review --- Comment #6 from Siebrand 2009-06-11 09:03:39 UTC --- +need-review -- 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 7208] Change font for texvc-generated images
https://bugzilla.wikimedia.org/show_bug.cgi?id=7208 Miraceti changed: What|Removed |Added CC||hofm...@aldebaran.cz --- Comment #7 from Miraceti 2009-06-11 09:02:54 UTC --- I would also like to see some solution of this problem. The font used in a text is about "small" (css keyword) nowadays, as it is common in the Web. The font used for generating formulas in png is significantly larger and it is a serif font. This breaks the whole page often and special style guide-lines are to be kept if the page should be at least a bit readable. The problem is nicely illustrated in existence of http://en.wikipedia.org/wiki/Template:Bigmath . If the formulas were displayed well, no such template would be necessary. There are two possible solutions: 1) Leave a common Web font habits and start to use "medium" size fonts in common text. Medium size is closer (for most users) to the font size used in png formulas. 2) Change the font size in png formulas to smaller. Unfortunately, this can affect the readability of the formulas. I understand the solution will never be perfect for everybody and it will always have drawbacks. Users use different font size as their defaults. But let's make the problem at least smaller if it cannot be solved completely. Another, let's say "half solution", would be allowing editors to change the font in png formulas at least in cases when formula is inline. "\textstyle" in TeX changes the way how the formula is typed but does not change the font size. Math template ( http://en.wikipedia.org/wiki/Template:Math ) is not always the solution and it is quite difficult to use (and the template itself must be implemented in every project separately). As a plus, it would be nice if the user of Wikimedia projects could easily switch between serif and sans-serif fonts in their settings. "Serif font mode" would also make math articles more readable. I am not sure if png formulas in sans-serif fonts would be the best idea. -- 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 19153] Enable dng uploads on Commons
https://bugzilla.wikimedia.org/show_bug.cgi?id=19153 --- Comment #2 from Derrick Coetzee 2009-06-11 07:57:35 UTC --- Oops, excuse my naivity. DNG files are TIFF files, but with additional DNG-specific tags; they can be identified by the presence of a DNGVersion tag. See specification here: http://www.adobe.com/products/dng/pdfs/dng_spec_1_2_0_0.pdf Let me know if I can do anything to help. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 9119] Improper base font size
https://bugzilla.wikimedia.org/show_bug.cgi?id=9119
Miraceti changed:
What|Removed |Added
CC||hofm...@aldebaran.cz
--- Comment #5 from Miraceti 2009-06-11 07:53:50 UTC ---
The font size specified by x-small keyword is different on each platform (see
http://style.cleverchimp.com/font_size_intervals/altintervals.html ).
It's true that webpages use often smaller fonts than the default one.
Unfortunately. This has a historical reason. I my opinion, Wikimedia should
probably do the same until something happens in the outer world.
The "minimimum size" trick _does not work_ as Gabriel wanted. Try this in your
project:
Lorem
ipsum!
Lorem
ipsum!
Lorem ipsum!
Both major browsers, Firefox 3.0 and IE 8 display all three texts in the same
way (however, Konqueror 3.5 does not). There is no real protection against too
small font.
In my opionion, if Wikimedia projects really wants to use an advantage of
keywords, only keywords should be used. For special cases like menus, it is
possible to use percentage in addition at the last level of a style definition
but the number of font sizes on a page should be limited. No 127% * 95% * 95%
should be used because it only complicates the design and makes keywords
impossible to use in higher levels of the style definition.
I suggest to leave the concept of globalWrapper or use it for something else
than changing font size. Let's keep things simple. The css should look like
this:
/* Font size:
** We take advantage of keyword scaling
** More at http://www.w3.org/2003/07/30-font-size
** http://style.cleverchimp.com/font_size_intervals/altintervals.html
*/
body {
font: small sans-serif;
background: #f9f9f9 url(headbg.jpg) 0 0 no-repeat;
color: black;
margin: 0;
padding: 0;
}
/* wrapper for free use */
#globalWrapper {
/* empty by default */
}
This change won't have a significant impact on an ordinary user since "x-small"
* 127% is about the same as "small" on major platforms. However it makes the
whole css simpler and more understandable.
--
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 19149] Create autopatroller group on Bulgarian Wikipedia
https://bugzilla.wikimedia.org/show_bug.cgi?id=19149 JeLuF changed: What|Removed |Added CC||je...@gmx.de Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from JeLuF 2009-06-11 07:48:04 UTC --- Done. -- 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 19153] Enable dng uploads on Commons
https://bugzilla.wikimedia.org/show_bug.cgi?id=19153 JeLuF changed: What|Removed |Added CC||je...@gmx.de Component|General/Unknown |Images and files Keywords|shell | Product|Wikimedia |MediaWiki --- Comment #1 from JeLuF 2009-06-11 07:44:51 UTC --- Adding it to wgFileExtensions is not sufficient. First of all, we'd need a verifier that checks whether a file is really a DNG file. Just checking for the extension is not enough. Some browsers try to "guess" whether a file is HTML, and we must make sure that noone uploads HTML files disguised as DNG files. (shell keyword removed, code changes are needed first) -- 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
