[Bug 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 --- Comment #8 from Daniel Friesen mediawiki-b...@nadir-seen-fire.com 2011-10-26 06:32:04 UTC --- I had an extension to this idea in dumps/export/import. We update the dump format to also include the =USER =SMW_PROPERTY etc... key that the namespace was registered with. At that point, during an import we have the information we need to actually pre-register a namespace during an import. And it'll even work with extensions like SMW since the keys are preserved. The namespace will be imported, it'll work even if the extension is not installed. And when the extension is installed, it'll just pick up on the contents already in the namespace. Some of these ideas make me think that custom site namespaces should be registered with some sort of SITE_X key that carries the implication that the namespace was created for a site-specific purpose and the same key from two different wikis may not actually be equivalent in any way. -- 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 29005] Unnecessary unicode Char code change
https://bugzilla.wikimedia.org/show_bug.cgi?id=29005 --- Comment #25 from sunil vss...@gmail.com 2011-10-26 06:38:29 UTC --- (In reply to comment #23) (In reply to comment #22) Is there no font that can show all characters without hacking? Only one, AnjaliOldLipi, among popular fonts and used by WebFonts. It is what second para of comment #19 referring. Now aruna also shows well. http://sourceforge.net/projects/aruna/ -- 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 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 --- Comment #9 from Gregor Hagedorn g.m.haged...@gmail.com 2011-10-26 07:05:00 UTC --- I agree. Registering and exporting/importing symbolic names like name=SMW_PROPERTY would make a lot of sense and be more flexible than relying on the key=102 etc. numbers. The xml format extension would be trivial, but it may a deep change in import/export management. I don't think that SITE_001 is necessary, simply omitting the name attribute would suffice. For internal management, rather than adding a special table for this, I would prefer to add this to the MediaWiki: namespace. -- 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 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 --- Comment #10 from Daniel Friesen mediawiki-b...@nadir-seen-fire.com 2011-10-26 07:31:39 UTC --- (In reply to comment #9) I agree. Registering and exporting/importing symbolic names like name=SMW_PROPERTY would make a lot of sense and be more flexible than relying on the key=102 etc. numbers. The xml format extension would be trivial, but it may a deep change in import/export management. I don't think that SITE_001 is necessary, simply omitting the name attribute would suffice. We might do that for export. I was considering it. Internally though I believe we may end up doing things like passing around the SMW_PROPERTY string instead of passing around 102 or whatever. Hence we may need something like SITE_X that carries that implication. We may just make one of those implications an implication that the ns does not output an identifier into export. For internal management, rather than adding a special table for this, I would prefer to add this to the MediaWiki: namespace. Hell no. - We should not need to load the whole i18n system before we load the namespace system. The namespace system should be lighter than that. The i18n system has a whole multi-layer structure (get messages from a cache, potentially share messages across multiple systems, get messages from MediaWiki: [this can be disabled too], get messages from i18n files, get messages from core i18n files). Namespace mapping should not be dependent on this. -- Actually I believe that the way that Wikimedia shares messages would make this impossible to work on WM as namespace info should be wiki-local. - Using a database table rather than pages means that we can actually table join it. Instead of the current substandard we have you could actually do a page, namespace join with something like `ns_id = page_namespace` and `title = CONCAT(ns_text, ':', page_title)` and get out a REAL title. - Storing this information in the user editable namespace also has other implications, like making it less efficient and requiring extra db queries to do something simple, and even worse has the potential to let a user completey break their wiki by screwing up something in the MediaWiki: namespace and make it impossible to correct without manual db tweaks. It's also a horrible interface for letting users configure their wiki. - The fact that a namespace registration system may register the ns number for MediaWiki: and that namespace registration may depend on extracting things from the MediaWiki: namespace means that we have a circular dependency. This is a horrible system design. Heck the i18n system defines aliases for namespaces which means that the namespace system might need to be loaded before the i18n system is loaded anyways. - MediaWiki: is an absolute horrible place for configuration. This is our i18n system, it's for translations, NOT for configuration. The i18n people hate the fact that this stuff is in there. And others of us want to kill off the i18n hacks we have and turn them into proper site configuration systems. -- 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 31832] Collapsing mw-collapsible tables is notably delayed (broken animation) in all browsers
https://bugzilla.wikimedia.org/show_bug.cgi?id=31832
--- Comment #10 from Erwin Dokter er...@darcoury.nl 2011-10-26 07:33:58 UTC
---
jQuery animates elements by manipulating their CSS properties in 'realtime'. It
is not just the speed if the javascript engine that matters, but also the speed
of the browser's rendering engine, which is very dependent on the machine's
capabilities. Old video cards/drivers are prone to stalling while rendering the
animations. Perhaps Opera has trouble calculating the opacity to render the
fade effect.
I agree that tables should simply slide up/down in 200ms ('fast').
--
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 31345] Parameters rvdir, rvuser, and rvexcludeuser are not marked (enum)
https://bugzilla.wikimedia.org/show_bug.cgi?id=31345 Antoine hashar Musso has...@free.fr changed: What|Removed |Added Status|RESOLVED|VERIFIED Version|1.19-svn|1.18 --- Comment #2 from Antoine hashar Musso has...@free.fr 2011-10-26 07:47:40 UTC --- This happened also in 1.18 and my change got merged. Should be in next tarball. Thanks for your 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 31832] Collapsing mw-collapsible tables is notably delayed (broken animation) in all browsers
https://bugzilla.wikimedia.org/show_bug.cgi?id=31832 --- Comment #11 from Daniel Friesen mediawiki-b...@nadir-seen-fire.com 2011-10-26 08:00:21 UTC --- jQuery doesn't even bother to use requestAnimationFrame yet. There was a bug on it (which was supposedly marked fixed , and a pull request, but it doesn't look like the code has even made it into HEAD of master much less a stable release yet. -- 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 31477] Android app can get in state where clicking links, search area, or menu items has no effect
https://bugzilla.wikimedia.org/show_bug.cgi?id=31477 Tomasz Finc tf...@wikimedia.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Tomasz Finc tf...@wikimedia.org 2011-10-26 08:10:00 UTC --- Resolving as we haven't been able to duplicate this. Please re-open if you can reliably reproduce this. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 31447] Tracking bug for 1.0 release of Android App
https://bugzilla.wikimedia.org/show_bug.cgi?id=31447 Bug 31447 depends on bug 31477, which changed state. Bug 31477 Summary: Android app can get in state where clicking links, search area, or menu items has no effect https://bugzilla.wikimedia.org/show_bug.cgi?id=31477 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 31869] Android app should not forget that its just done a near by me search if the location hasn't changed
https://bugzilla.wikimedia.org/show_bug.cgi?id=31869 Tomasz Finc tf...@wikimedia.org changed: What|Removed |Added Priority|Unprioritized |Normal -- 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 31891] Android app nearby me should have a mechanism to show more or less results
https://bugzilla.wikimedia.org/show_bug.cgi?id=31891 Tomasz Finc tf...@wikimedia.org changed: What|Removed |Added Blocks||31805 -- 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 31805] Tracking bug for 1.1 release of Android App
https://bugzilla.wikimedia.org/show_bug.cgi?id=31805 Tomasz Finc tf...@wikimedia.org changed: What|Removed |Added Depends on||31891 -- 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 31832] Collapsing mw-collapsible tables is notably delayed (broken animation) in all browsers
https://bugzilla.wikimedia.org/show_bug.cgi?id=31832 --- Comment #12 from TMg mr.h...@gmx.de 2011-10-26 08:21:36 UTC --- (In reply to comment #9) But it seems a bit odd that the fade just _doesn't work_ on Opera No, it does not work in ALL browsers. Nothing is animated in Internet Explorer, nothing is animated in Opera. In Firefox the WRONG property is animated (the color) as explained above multiple times. This is true for tables. The situation is a bit better for DIV elements, but not much. The animation is also horribly slow, useless, wasting time, and depending on the situation where it's used it's often misplaced, does not make sense, creates graphical clutter, is distracting, flickering, ... I think you get it. The main reason for adding an animation to mw-collapsible elements is the animation itself. Look, we are so cool, we can abuse JavaScript to make parts of the site you are reading float around. -- 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 31951] New: Intergrate Extension:Interwiki into mediawiki core
https://bugzilla.wikimedia.org/show_bug.cgi?id=31951 Web browser: --- Bug #: 31951 Summary: Intergrate Extension:Interwiki into mediawiki core Product: MediaWiki Version: 1.19-svn Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Unprioritized Component: Special pages AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: g.m.haged...@gmail.com Classification: Unclassified Managing interwiki links is a basic activity that almost every new mediawiki setup has to do. For example, the predefined list of interwiki links does not contain links to language versions of wikipedia, one of the first needs for many installations. Mediawiki core presently assumes that interwiki is being managed by SQL database statements from the command line. This is not realistic for many mediawiki installations and limits the usability of the software. An excellent extension exists: Extension:Interwiki but is hidden among a set of similar extensions. See review on top of http://www.mediawiki.org/wiki/Category:Interwiki_extensions While the review helps, a less frustrating solution would be to intergrate the extension into core. -- 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 31952] New: Android app should show a spinner when we are attempting to load a page
https://bugzilla.wikimedia.org/show_bug.cgi?id=31952 Web browser: --- Bug #: 31952 Summary: Android app should show a spinner when we are attempting to load a page Product: Wikimedia Mobile Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: android AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: tf...@wikimedia.org CC: herman.w...@nitobi.com, tf...@wikimedia.org Classification: Unclassified While its great that we show an X to stop a page load, lets also show a spinner to tell the user that were actively working. We could either put it at the bottom right or replace the X in the search bar like most other android apps. -- 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 31952] Android app should show a spinner when we are attempting to load a page
https://bugzilla.wikimedia.org/show_bug.cgi?id=31952 Tomasz Finc tf...@wikimedia.org changed: What|Removed |Added Priority|Unprioritized |Normal -- 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 31952] Android app should show a spinner when we are attempting to load a page
https://bugzilla.wikimedia.org/show_bug.cgi?id=31952 Tomasz Finc tf...@wikimedia.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Tomasz Finc tf...@wikimedia.org 2011-10-26 08:30:07 UTC --- *** This bug has been marked as a duplicate of bug 31483 *** -- 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 31483] Android app doesn't show a spinner or progress bar on most page loads
https://bugzilla.wikimedia.org/show_bug.cgi?id=31483 --- Comment #4 from Tomasz Finc tf...@wikimedia.org 2011-10-26 08:30:08 UTC --- *** Bug 31952 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 31953] New: Extension blocked (Exception Encountered)
https://bugzilla.wikimedia.org/show_bug.cgi?id=31953
Web browser: ---
Bug #: 31953
Summary: Extension blocked (Exception Encountered)
Product: MediaWiki
Version: 1.18
Platform: PC
OS/Version: Windows 7
Status: NEW
Severity: critical
Priority: Unprioritized
Component: API
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: habatc...@aol.com
CC: bryan.tongm...@gmail.com, roan.katt...@gmail.com,
s...@reedyboy.net, soxre...@gmail.com
Classification: Unclassified
The Book Creator (Collections) extension on the main Wikipedia site is blocked
and does not execute as expected.
SitRep: The user interface on the main Wikipedia site generates the statement:
Unexpected non-MediaWiki exception encountered, of type UsageException
badtoken: Invalid token
#0 /usr/local/apache/common-local/php-1.18/includes/api/ApiBase.php(1205):
ApiBase-dieUsage('Invalid token', 'badtoken')
#1 /usr/local/apache/common-local/php-1.18/includes/api/ApiMain.php(590):
ApiBase-dieUsageMsg('sessionfailure')
#2 /usr/local/apache/common-local/php-1.18/includes/api/ApiMain.php(678):
ApiMain-setupModule()
#3 /usr/local/apache/common-local/php-1.18/includes/api/ApiMain.php(340):
ApiMain-executeAction()
#4
/usr/local/apache/common-local/php-1.18/extensions/Collection/Collection.body.php(867):
ApiMain-execute()
#5
/usr/local/apache/common-local/php-1.18/extensions/Collection/Collection.body.php(225):
SpecialCollection-saveCollection(Object(Title), false)
#6
/usr/local/apache/common-local/php-1.18/includes/SpecialPageFactory.php(460):
SpecialCollection-execute(NULL)
#7 /usr/local/apache/common-local/php-1.18/includes/Wiki.php(224):
SpecialPageFactory::executePath(Object(Title), Object(RequestContext))
#8 /usr/local/apache/common-local/php-1.18/includes/Wiki.php(624):
MediaWiki-performRequest()
#9 /usr/local/apache/common-local/php-1.18/includes/Wiki.php(531):
MediaWiki-main()
#10 /usr/local/apache/common-local/php-1.18/index.php(57): MediaWiki-run()
#11 /usr/local/apache/common-local/live-1.5/index.php(3):
require('/usr/local/apac...')
#12 {main}
This occurs at the point of executing the Special:Book output page as called
from with the application when completing the save book function.
Situation does not provide any further details concerning the nature of the
exception or if the user namespace has appropriate authorization to fix the
exception.
--
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 31954] New: Android app should allow user to select another near by listing without hitting the hardware button
https://bugzilla.wikimedia.org/show_bug.cgi?id=31954 Web browser: --- Bug #: 31954 Summary: Android app should allow user to select another near by listing without hitting the hardware button Product: Wikimedia Mobile Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: android AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: tf...@wikimedia.org CC: herman.w...@nitobi.com, tf...@wikimedia.org Classification: Unclassified Lets not force the user to use the hardware button when they could easily just tap on another map location -- 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 31954] Android app should allow user to select another near by listing without hitting the hardware button
https://bugzilla.wikimedia.org/show_bug.cgi?id=31954 Tomasz Finc tf...@wikimedia.org changed: What|Removed |Added Priority|Unprioritized |Normal -- 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 31955] New: Include Interwiki information in import and export xml files
https://bugzilla.wikimedia.org/show_bug.cgi?id=31955 Web browser: --- Bug #: 31955 Summary: Include Interwiki information in import and export xml files Product: MediaWiki Version: 1.19-svn Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: Export/Import AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: g.m.haged...@gmail.com Classification: Unclassified As it says. Presently Mediawiki imports fails because the interwiki links are not provided. New interwiki links should be imported. Conflicts occurring during import should be reported. -- 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 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 --- Comment #11 from Gregor Hagedorn g.m.haged...@gmail.com 2011-10-26 08:36:23 UTC --- That was a hornet nest, ok... I am almost convinced by the circular loading argument. Except I have a preference for wikis, that is: put things into a transparent, editable object repository and harvest from there. Like Categories and everything else. There is nothing wrong with having a namespace table, it could easily be harvested off MediaWiki: - except that would mean hardcoding the symbolic name for Mediawiki NS. Advantage: changes are tracked, editability is free (ultimately extensions should probably register their namespace, but for a long time this would require user interaction). I wish the same were true for the interwiki table: store as a transparent, changeable, version traceable object rather than as database table without version control and user interface. The present interwiki table, would be a bad example of how to manage namespaces. It is not included in import/export. It remains uneditable for how many years? 1000s of people trying to use mediawiki have to figure out which of http://www.mediawiki.org/wiki/Category:Interwiki_extensions they need to install. How many give up? I am adding bug 31951 to call for moving Extension:Interwiki to core, and bug 31955 to address the import/export question for interwiki. I am not a developer, only a mediawiki farm manager and applied user, so I fully accept your insight into the code structure which I don't have! -- 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 31956] New: Android app nearby me should offer a list view
https://bugzilla.wikimedia.org/show_bug.cgi?id=31956 Web browser: --- Bug #: 31956 Summary: Android app nearby me should offer a list view Product: Wikimedia Mobile Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Unprioritized Component: android AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: tf...@wikimedia.org CC: herman.w...@nitobi.com, tf...@wikimedia.org Classification: Unclassified If it becomes too hard to navigate responses on a map lets surface a list view like this http://meta.wikimedia.org/wiki/File:Wiki_0021_NearbyListView.png -- 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 31956] Android app nearby me should offer a list view
https://bugzilla.wikimedia.org/show_bug.cgi?id=31956 Tomasz Finc tf...@wikimedia.org changed: What|Removed |Added Priority|Unprioritized |Normal -- 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 31957] New: Android app nearby me should allow user to redo search after map move
https://bugzilla.wikimedia.org/show_bug.cgi?id=31957 Web browser: --- Bug #: 31957 Summary: Android app nearby me should allow user to redo search after map move Product: Wikimedia Mobile Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Unprioritized Component: android AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: tf...@wikimedia.org CC: herman.w...@nitobi.com, tf...@wikimedia.org Classification: Unclassified A user might want to refocus the map and then redo their search. http://meta.wikimedia.org/wiki/File:Wiki_0016_NearbyMap_RedoSearch.png -- 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 31957] Android app nearby me should allow user to redo search after map move
https://bugzilla.wikimedia.org/show_bug.cgi?id=31957 Tomasz Finc tf...@wikimedia.org changed: What|Removed |Added Priority|Unprioritized |Normal -- 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 31821] Special:Book not allowing saving
https://bugzilla.wikimedia.org/show_bug.cgi?id=31821
Stamm gillespeyr...@hotmail.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |
--- Comment #3 from Stamm gillespeyr...@hotmail.com 2011-10-26 08:54:50 UTC
---
The textbox is now enabled but when clicking on the button to save the book,
the following exception is thrown (as indicated by the first comment):
Unexpected non-MediaWiki exception encountered, of type UsageException
badtoken: Invalid token
#0 /usr/local/apache/common-local/php-1.18/includes/api/ApiBase.php(1205):
ApiBase-dieUsage('Invalid token', 'badtoken')
#1 /usr/local/apache/common-local/php-1.18/includes/api/ApiMain.php(590):
ApiBase-dieUsageMsg('sessionfailure')
#2 /usr/local/apache/common-local/php-1.18/includes/api/ApiMain.php(678):
ApiMain-setupModule()
#3 /usr/local/apache/common-local/php-1.18/includes/api/ApiMain.php(340):
ApiMain-executeAction()
#4
/usr/local/apache/common-local/php-1.18/extensions/Collection/Collection.body.php(867):
ApiMain-execute()
#5
/usr/local/apache/common-local/php-1.18/extensions/Collection/Collection.body.php(225):
SpecialCollection-saveCollection(Object(Title), true)
#6
/usr/local/apache/common-local/php-1.18/includes/SpecialPageFactory.php(460):
SpecialCollection-execute(NULL)
#7 /usr/local/apache/common-local/php-1.18/includes/Wiki.php(224):
SpecialPageFactory::executePath(Object(Title), Object(RequestContext))
#8 /usr/local/apache/common-local/php-1.18/includes/Wiki.php(624):
MediaWiki-performRequest()
#9 /usr/local/apache/common-local/php-1.18/includes/Wiki.php(531):
MediaWiki-main()
#10 /usr/local/apache/common-local/php-1.18/index.php(57): MediaWiki-run()
#11 /usr/local/apache/common-local/live-1.5/index.php(3):
require('/usr/local/apac...')
#12 {main}
--
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 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 --- Comment #12 from Daniel Friesen mediawiki-b...@nadir-seen-fire.com 2011-10-26 09:02:52 UTC --- (In reply to comment #11) That was a hornet nest, ok... I am almost convinced by the circular loading argument. Except I have a preference for wikis, that is: put things into a transparent, editable object repository and harvest from there. Like Categories and everything else. There is nothing wrong with having a namespace table, it could easily be harvested off MediaWiki: - except that would mean hardcoding the symbolic name for Mediawiki NS. Advantage: changes are tracked, editability is free (ultimately extensions should probably register their namespace, but for a long time this would require user interaction). There's nothing editable at all about formats like MediaWiki:Sidebar. They're horrible hacks with horrible interfaces for what could be a very user friendly special page. And while it's not versioning if we need it we already have a logging system. I wish the same were true for the interwiki table: store as a transparent, changeable, version traceable object rather than as database table without version control and user interface. The present interwiki table, would be a bad example of how to manage namespaces. It is not included in import/export. It remains uneditable for how many years? 1000s of people trying to use mediawiki have to figure out which of http://www.mediawiki.org/wiki/Category:Interwiki_extensions they need to install. How many give up? I am adding bug 31951 to call for moving Extension:Interwiki to core, and bug 31955 to address the import/export question for interwiki. I actually have a separate issue with interwiki. IMHO it shouldn't even be necessary to do database changes to change the interwiki table. For a simple wiki with fs access it should be as simple as editing a file. Default interwiki mappings should be done by referring to a core provided file as the default fallback instead of being inserted into the db on install. Wiki farms should be able to have a central interwiki database AND a local interwiki database with overrides, instead of being stuck with either a central one and no overrides or redundant local tables. etc... I am not a developer, only a mediawiki farm manager and applied user, so I fully accept your insight into the code structure which I don't have! -- 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 31941] Redirect checking during link entering
https://bugzilla.wikimedia.org/show_bug.cgi?id=31941 --- Comment #4 from Ianusius ianus...@rocketmail.com 2011-10-26 09:10:09 UTC --- Yes, that is correct. Sometimes redirects were created instead of misspelling pages. I did not mean that linking to redirects must be disallowed but that there is just a small hint. It is bad for IP users when you link to redirects because they often see a old version, ~ 5 days ago (open a new 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 31428] Interwiki map update (protocol relative)
https://bugzilla.wikimedia.org/show_bug.cgi?id=31428 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #9 from Roan Kattouw roan.katt...@gmail.com 2011-10-26 09:22:19 UTC --- There was a bug (or rather an unwanted feature) in dumpInterwiki.php that forced all URLs that look like WMF URLs to protocol-relative, even if they came from the interwiki map and had a protocol. I removed this in r100798 and re-ran the script; it's fixed now. -- 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 20342] Support for protocol-relative URLs (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=20342 Bug 20342 depends on bug 31428, which changed state. Bug 31428 Summary: Interwiki map update (protocol relative) https://bugzilla.wikimedia.org/show_bug.cgi?id=31428 What|Old Value |New Value Status|REOPENED|RESOLVED Resolution||FIXED -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 --- Comment #13 from Gregor Hagedorn g.m.haged...@gmail.com 2011-10-26 09:24:08 UTC --- 1. Having a nice editor for mw:Sidebar would be nice. But nothing in the present format prevents this, it just does not happen due to resource limitation. If it were not in Mediawiki: it would not be editable at all. 2. I don't think logging is a solution, it has not comparison function and is generally rather intransparent. One of the reasons is that user contributions and user logs must be checked separately, rather than being available in a single list. Interestingly, in recent changes they are unified... 3. Wiki admins have neither fileserver nor database access in the installations I know. Since developers have these, they usually believe everyone else has as well. I don't think files are good solution for interwiki. (4. Yes, the interwiki table is broken, among other things because it manages interlanguage and interwiki in a single table, which prevents sharing the interwiki links by using a shared table. But, perhaps it might be more difficult to update because it is is a non-wiki, classical database design of a dedicated table that is directly edited by third-party tools. If interwiki were harvested and opaque, the update may be more easy. But maybe not...) -- 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 19437] centralnotice.js should be served compressed and from bits.
https://bugzilla.wikimedia.org/show_bug.cgi?id=19437 --- Comment #15 from Roan Kattouw roan.katt...@gmail.com 2011-10-26 09:25:52 UTC --- (In reply to comment #14) I've archived the contents of /mnt/upload6/centralnotice. I can't, however, remove the directory as I do not have sufficient permissions to remove everything (many things are owned by apache and in the apache group and I don't have r00t). Roan, can you take care of that? I'll delete it once you're awake and on IRC, so we can restore it quickly if anything bad happens. -- 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 31950] Need updated fonts for Malayalam in Server
https://bugzilla.wikimedia.org/show_bug.cgi?id=31950 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added CC||roan.katt...@gmail.com --- Comment #1 from Roan Kattouw roan.katt...@gmail.com 2011-10-26 09:38:04 UTC --- I don't quite understand this bug. When are server-side fonts ever used to render wiki pages? Wiki pages are just HTML, rendered using client-side fonts, right? -- 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 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 --- Comment #14 from Daniel Friesen mediawiki-b...@nadir-seen-fire.com 2011-10-26 09:54:32 UTC --- (In reply to comment #13) 1. Having a nice editor for mw:Sidebar would be nice. But nothing in the present format prevents this, it just does not happen due to resource limitation. If it were not in Mediawiki: it would not be editable at all. The present format is a mess. And the checks to modify pages necessary for a Special: page to update the sidebar with our full functionality are insane. A special page updating a sidebar could potentially have to simultaneously edit a half dozen pages. Check that the current user has edit permissions on all of them, if an edit-conflict happens on ANY of them while it's editing it would have to figure out what to do with a half state, and it would have to output multiple entries into the rc instead of a single sane line showing the user has updated the sidebar. 2. I don't think logging is a solution, it has not comparison function and is generally rather intransparent. One of the reasons is that user contributions and user logs must be checked separately, rather than being available in a single list. Interestingly, in recent changes they are unified... Then file a bug asking for a 'user changes' page that unifies contribs and logs. And really do you need a comparison function for the change Dantman added the Foo: namespace, or Dantman enabled subpages on Help:? By the way, namespace updates require checks into what pages are using the namespaces or prefix and a pile of database updates for any relevant pages. By the way, currently if you want to add a namespace you have to do those db updates manually. A Special: page would do these implicitly. But a MediaWiki: page wouldn't, and would expose a site admin to breakage that can only be fixed by someone with database access and in-depth knowledge of how to fix the issue. 3. Wiki admins have neither fileserver nor database access in the installations I know. Since developers have these, they usually believe everyone else has as well. I don't think files are good solution for interwiki. And some wiki are administrated by the user who does have fs access, who shouldn't have to do something as heavy as db or web stuff when file editing is easy for them. What I'm describing is a configurable multi-layered interwiki system. If file editing is easy for you, then use file editing tools. If you want Special: page editability use a layer with a database and use the Special: page that would come with that multi-layer change. In fact the editability would probably be done by implementing functions on read-write interwiki sources to make changes so any Special: page for editing interwikis could work with any read-write source whether it's database or file based. (4. Yes, the interwiki table is broken, among other things because it manages interlanguage and interwiki in a single table, which prevents sharing the interwiki links by using a shared table. But, perhaps it might be more difficult to update because it is is a non-wiki, classical database design of a dedicated table that is directly edited by third-party tools. If interwiki were harvested and opaque, the update may be more easy. But maybe not...) -- 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 31951] Intergrate Extension:Interwiki into mediawiki core
https://bugzilla.wikimedia.org/show_bug.cgi?id=31951 Daniel Friesen mediawiki-b...@nadir-seen-fire.com changed: What|Removed |Added CC||mediawiki-bugs@nadir-seen-f ||ire.com --- Comment #1 from Daniel Friesen mediawiki-b...@nadir-seen-fire.com 2011-10-26 10:03:33 UTC --- Relevant related bug and pages: bug 22043 https://www.mediawiki.org/wiki/Suggestions_for_extensions_to_be_integrated#Interwiki -- 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 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 --- Comment #15 from Gregor Hagedorn g.m.haged...@gmail.com 2011-10-26 10:19:54 UTC --- A special page updating a sidebar could potentially have to simultaneously edit a half dozen pages. Check that the current user has edit permissions on all of them, if an edit-conflict happens on ANY of them while it's editing it would have to figure out what to do with a half state, and it would have to output multiple entries into the rc instead of a single sane line showing the user has updated the sidebar. I cannot follow, I think the only distributed thing is the localization of the menu into multiple languages, which, unless everything is changed, would have to remain in Mediawiki NS. And yes, the Sidebar page could be easier to parse and get a new syntax. But that does not requiring to add a whole new set of tables for it. Create a Mediawiki:Sidebar.json, which, if present, overrides any available Sidebar... And really do you need a comparison function for the change Dantman added the Foo: namespace, or Dantman enabled subpages on Help:? Of course not, I am referring to your proposal that logging does well enough to understand changes in interwiki. But perhaps you can get away with Dantman changed the interwiki prefix en from en.wikipedia to xxx. provided you can filter all interwiki logs. What I'm describing is a configurable multi-layered interwiki system. If file editing is easy for you, then use file editing tools. If you want Special: page ... No objections if resources are available for both file and Special: page and all use cases are covered - that would be great! (Just a thought: If file, please place an additional file in a place specifiable in LocalSettings, rather than requiring to modify code-base provided files (as currently, e.g. mime.types). The latter causes issues with wikifarms, svn-checkouts, updating, etc.) -- 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 31953] Extension blocked (Exception Encountered)
https://bugzilla.wikimedia.org/show_bug.cgi?id=31953 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added CC||developm...@pediapress.com Component|API |Collection Version|1.18|any Product|MediaWiki |MediaWiki extensions -- 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 31953] Extension blocked (Exception Encountered)
https://bugzilla.wikimedia.org/show_bug.cgi?id=31953 Christoph Kepper christoph.kep...@pediapress.com changed: What|Removed |Added Status|NEW |RESOLVED CC||christoph.kepper@pediapress ||.com Resolution||DUPLICATE --- Comment #1 from Christoph Kepper christoph.kep...@pediapress.com 2011-10-26 10:40:34 UTC --- *** This bug has been marked as a duplicate of bug 31613 *** -- 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 31613] API UsageException when saving a collection to a page
https://bugzilla.wikimedia.org/show_bug.cgi?id=31613 Christoph Kepper christoph.kep...@pediapress.com changed: What|Removed |Added CC||habatc...@aol.com --- Comment #3 from Christoph Kepper christoph.kep...@pediapress.com 2011-10-26 10:40:34 UTC --- *** Bug 31953 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 31821] Special:Book not allowing saving
https://bugzilla.wikimedia.org/show_bug.cgi?id=31821 --- Comment #4 from Christoph Kepper christoph.kep...@pediapress.com 2011-10-26 10:45:09 UTC --- AFIK this is a bug in the API that was already documented in bug 31613 -- 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 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 --- Comment #16 from Daniel Friesen mediawiki-b...@nadir-seen-fire.com 2011-10-26 11:05:55 UTC --- (In reply to comment #15) A special page updating a sidebar could potentially have to simultaneously edit a half dozen pages. Check that the current user has edit permissions on all of them, if an edit-conflict happens on ANY of them while it's editing it would have to figure out what to do with a half state, and it would have to output multiple entries into the rc instead of a single sane line showing the user has updated the sidebar. I cannot follow, I think the only distributed thing is the localization of the menu into multiple languages, which, unless everything is changed, would have to remain in Mediawiki NS. Yup, they're all in the MediaWiki: NS but when a translations are changed every relevant page has to be changed simultaneously. And the code has to take this into account. Additionally our permissions systems are per-page not per-namespace, and unless the code ensures that permissions are checked for each page individually it's not a proper core feature, it's a hack, and it doesn't follow the expectation that ACL extensions expect when they hook into our hooks for permissions tests. And yes, the Sidebar page could be easier to parse and get a new syntax. But that does not requiring to add a whole new set of tables for it. Create a Mediawiki:Sidebar.json, which, if present, overrides any available Sidebar... Hell no. Not only is the i18n system not a configuration system, it's also not a place to include a very strict and technical format. It shouldn't be possible for a user to edit what the special page stores, accidentally screw up the syntax, and then make it so that the special page can't fix what they broke. By the way, php's json pretty printing isn't implemented till 5.4.0, and that is an alpha. No stable version of php has a native json encoder with the capability to pretty print json. So because there is no pretty printing, any json outputted by the Special: page into a .json i18n page will be in one long line, not pretty printed with each item on a separate line. So if you want comparison, a Sidebar.json will look like shit. Our 'diff' will be almost entirely useless for figuring out the difference between two versions of the sidebar. And really do you need a comparison function for the change Dantman added the Foo: namespace, or Dantman enabled subpages on Help:? Of course not, I am referring to your proposal that logging does well enough to understand changes in interwiki. But perhaps you can get away with Dantman changed the interwiki prefix en from en.wikipedia to xxx. provided you can filter all interwiki logs. Special:Log/interwiki One of the reasons logs are separate from contribs is because they have separate filtering features. Contribs can filter by namespace, logs can filter by type and title. What I'm describing is a configurable multi-layered interwiki system. If file editing is easy for you, then use file editing tools. If you want Special: page ... No objections if resources are available for both file and Special: page and all use cases are covered - that would be great! (Just a thought: If file, please place an additional file in a place specifiable in LocalSettings, rather than requiring to modify code-base provided files (as currently, e.g. mime.types). The latter causes issues with wikifarms, svn-checkouts, updating, etc.) The plan I hoped for was to implement multiple interwiki source types. File (piped list, csv, json, xml, plist, etc...), Database (default database, separate database, separate database and user credentials), etc... and have a $wg variable like our $wgForeignFileRepos that lists multiple interwiki sources letting you use order to specify what sources override other sources. The default list would contain a file located inside core for our interwiki defaults. If you don't want those you'd just override the entire way and only specify sources you want yourself. If you want a file source you would add that to the list yourself including the path to that file yourself, so it's completely customizable. You could even implement wiki farm specifics by having a central interwiki source, a project wide interwiki source, and a wiki specific interwiki source. Any of those could be files or databases. -- 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 31836] Android app has some empty/blank menu items on Android 4.0 / Ice Cream Sandwich emulator
https://bugzilla.wikimedia.org/show_bug.cgi?id=31836 Armin wikipe...@coralic.nl changed: What|Removed |Added CC||wikipe...@coralic.nl --- Comment #2 from Armin wikipe...@coralic.nl 2011-10-26 11:49:51 UTC --- I tried to reproduce this issue on 2.3.3 (emulator), 4.0 (emulator), 2.3.7 (cyanogenmod Galaxy S) but was not able to. Is this still an issue? Brion can you confirm? -- 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 29493] Fix parser fuzz tests - do not serialize PDO objects for starters
https://bugzilla.wikimedia.org/show_bug.cgi?id=29493 --- Comment #5 from Antoine hashar Musso has...@free.fr 2011-10-26 11:50:51 UTC --- Xdebug does not like this test! $ ./phpunit.php --tap --filter FuzzTests includes/parser/NewParserTest.php Fatal error: Maximum function nesting level of '200' reached, aborting! snip: Call Stack There is a faulty recursion somewhere in our code :-( -- 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 29493] Fix parser fuzz tests - do not serialize PDO objects for starters
https://bugzilla.wikimedia.org/show_bug.cgi?id=29493 Antoine hashar Musso has...@free.fr changed: What|Removed |Added Status|NEW |ASSIGNED -- 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 31945] Enhanced watchlist freezes the browser for 30 seconds after loading a big list (the time is relative to the number of entries displayed)
https://bugzilla.wikimedia.org/show_bug.cgi?id=31945 --- Comment #6 from Saibo saibotr...@arcor.de 2011-10-26 12:16:28 UTC --- (In reply to comment #2) A few questions for clarification: * Is this happening on every show/hide of a specific group? Or only at page startup time (when all the groups get pre-collapsed)? Every show/hide is slower than before 1.18, too - but it just takes less than a second. Still annonying - but this isn't what the bug is about. The bug is about page startup when all entries are loaded and the JS kicks in and collapses the groups. * Is that a big total list -- Like 100 or 1000 or 1 separate edits being shown on the entire watchlist display? Or big in terms of a collapsed set of 10, 100, or 1000 edits on the same article that get shown/hidden together as a single group? I noticed that: the time taken is relative to the days (URL parameter) displayed; which is roughly relative to the number of displayed edits. I had a look in the Firebug Network view: https://commons.wikimedia.org/w/index.php?action=rawctype=text/csstitle=MediaWiki%3ACollapsibleTemplates.css is the last action. It takes this time on my current Commons watchlist: days |time (s) |edits | = edits/s 0.53 4715,6 1 1127024,5 2 2553121,2 3 4183924,5 Cannot test if the time is related to the number of edits or the number of groups. * What browser and version? As set in the bug details: Firefox 3.6 * What operating system and version? openSUSE 11.1 -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 31945] Enhanced watchlist freezes the browser for 30 seconds after loading a big list (the time is relative to the number of entries displayed)
https://bugzilla.wikimedia.org/show_bug.cgi?id=31945 --- Comment #7 from Saibo saibotr...@arcor.de 2011-10-26 12:20:46 UTC --- (In reply to comment #5) (Note that per the above analysis, the thing that'll cause the biggest slowdown is having _lots of initially-collapsed groups_ on the watchlist. So a lot of pages that have been edited multiple times; each collapsed group will add to the slowdown.) Yes, the majority of pages displayed in my watchlist have several edits → collapsed group. I have counted for days=1 → 265 edits in 51 groups. -- 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 31945] Enhanced watchlist freezes the browser for 30 seconds after loading a big list (the time is relative to the number of entries displayed)
https://bugzilla.wikimedia.org/show_bug.cgi?id=31945 --- Comment #8 from Saibo saibotr...@arcor.de 2011-10-26 12:22:22 UTC --- (In reply to comment #6) (where is the _edit_ button? .. crappy BZ) Machine: Pentium M 1,6 GHz (single core) -- 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 31911] Validator extension: #iferror does not recognize Validator's errors
https://bugzilla.wikimedia.org/show_bug.cgi?id=31911 --- Comment #5 from Jeroen De Dauw jeroen_ded...@yahoo.com 2011-10-26 12:31:49 UTC --- Validator actually has some notion of different error levels. However, this is not fully implemented. The part that is implemented is differentiation between fatal and non-fatal errors, the fatal ones causing the regular output to not be shown at all (ie render not getting called). It also has some support for choosing which errors you want to see (never show errors, show all but the most trivial ones (ie deprecation warnings)), ect. Again, this has not been fully implemented yet. Returning the span only for fatal errors might actually break some current code. Map for example will put the error message in a div with class error when there is a fatal error. This also ought to work with #iferror I guess. Even if it doesn't break it, it's still silly to do it at two points. Having some kind of stack trace would be nice, but might be difficult. No idea what this Fire PHP thing is. -- 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 31945] Enhanced watchlist freezes the browser for 30 seconds after loading a big list (the time is relative to the number of entries displayed)
https://bugzilla.wikimedia.org/show_bug.cgi?id=31945 --- Comment #9 from Saibo saibotr...@arcor.de 2011-10-26 12:32:33 UTC --- Tested with Opera 11.5 on the same machine: Interesting: Opera collapses the groups one by one starting on top with screen updates between each collapse. days |time (s) |edits | = edits/s 0.5N/A 1 726137 2 N/A 3 2083642 -- 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 31958] New: Enable per-page (e.g. by means of a tag on the page) Mediawiki-namespace-based javascript inclusion
https://bugzilla.wikimedia.org/show_bug.cgi?id=31958 Web browser: --- Bug #: 31958 Summary: Enable per-page (e.g. by means of a tag on the page) Mediawiki-namespace-based javascript inclusion Product: MediaWiki Version: 1.19-svn Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Unprioritized Component: Javascript AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: g.m.haged...@gmail.com CC: tpars...@wikimedia.org Classification: Unclassified BACKGROUND: Mediawiki has very small core of php developers. As a CMS, it is ages behind the abilities of Drupal 7 or other current systems. Unless building on the strength of the wiki concept, improving the ability of community members to develop and deploy javascript editors etc. without requiring server access, Mediawiki may fall behind even further. With jQuery and the resource loader renovated, opportunities are now excellent to pursue this path. Presently can be provided by php-developers (the small and - for good reason - tightly controlled community), by admins for all pages, or for individual users (self-created or as personally enabled widgets). For all pages is often too dangerous to become a basis for agile improvements, for one self is not very motivating. ENHANCEMENT REQUEST: What may be be missing is a hook that enables Mediawiki-ns-based javascript on a specific page (apologies if I overlook an existing feature). I propose to add a tag to load admin-provided scripts from the Mediawiki namespace. It could be javascriptMediawiki:XYZ.js/javascript or javascriptXYZ.js/javascript but should always be limited to the Mediawiki namespace. Such javascript is only executed for page on which the tag is present (in practice, the tag will most likely be included through templates). This could be the ground on which more agile experiments can be run, and on which topic-specific functionality is deployed by the community for the community. -- 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 31613] API UsageException when saving a collection to a page
https://bugzilla.wikimedia.org/show_bug.cgi?id=31613
Christoph Kepper christoph.kep...@pediapress.com changed:
What|Removed |Added
CC||christoph.kepper@pediapress
||.com
--- Comment #4 from Christoph Kepper christoph.kep...@pediapress.com
2011-10-26 12:56:12 UTC ---
As far as I can see, there is a logical problem in $wgUser-matchEditToken().
(includes/User.php L3228)
public function matchEditToken( $val, $salt = '', $request = null ) {
$sessionToken = $this-editToken( $salt, $request );
if ( $val != $sessionToken ) {
wfDebug( User::matchEditToken: broken session data\n \
);
}
return $val == $sessionToken;
}
The token ($val) has to be inserted in the request, but $sessionToken is hashed
with the request. Therefore, the token inserted in the request can NEVER match
the original $wgUser-editToken().
--
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 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 --- Comment #17 from Gregor Hagedorn g.m.haged...@gmail.com 2011-10-26 12:57:20 UTC --- (this is getting a tad too philosophical and away from the original bug - this was namespaces, not interwiki :-) - but I cannot resist the temptation:) You describe a lock it down as safely as you can-approach of a tightly managed CMS system. And you think of server-side code php. I was thinking of javascript for the sidebar editor. I think the Mediawiki namespace then is ideal because it allows mediawiki developers to provide initial javascript AND the admins and community experts to override it, just like they can override non-fitting translations. Sorry for the excursion... And today is bug submission day for me it seems, so I submitted the more general enhancement request bug 31958 on this topic... Thanks for your patience and your continued good work on 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 31259] Large numbers are rendered differently depending on which server is rendering them
https://bugzilla.wikimedia.org/show_bug.cgi?id=31259 --- Comment #15 from Peter Youngmeisterarius p...@wikimedia.org 2011-10-26 13:35:04 UTC --- Yes! This is fixed. Sorry for not noting sooner. Many bugs were closed by upgrading to lucid, and a couple slipped through the cracks. All active apaches are upgraded. This includes all of the mw[0-9][0-9] boxxies and all srv* boxxies, with the exception of those with external stores which have been removed from the load-balancing pools, and thus are not serving anything up via apache. -- 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 31947] fawikisource change author from مؤلف to پدیدآورنده
https://bugzilla.wikimedia.org/show_bug.cgi?id=31947 Bellavista1957 tahmor...@hotmail.com changed: What|Removed |Added Priority|Unprioritized |High Severity|normal |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 24915] Move CSS signatures from body to html
https://bugzilla.wikimedia.org/show_bug.cgi?id=24915 Daniel Friesen mediawiki-b...@nadir-seen-fire.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #6 from Daniel Friesen mediawiki-b...@nadir-seen-fire.com 2011-10-26 13:57:54 UTC --- Initial notes: - body.page-* is not unnecessarily specific, it's good practice to restrict signatures to the element signatures are placed on. - Admittedly charsets are not relevant, MediaWiki sanitizes any non-alphanumeric+-_ character in css classes. Specific to this idea of fixed-width centering vector: - Here's a base for fixed-width centering vector https://www.mediawiki.org/wiki/User:Dantman/vector-fixed.css - Have you actually bothered to test out the technique you're describing on vector? The css you specified doesn't work it needs more to actually make vector fixed-width. And when you actually manage to make vector fixed-width you realize that it's messed up: The backgrounds need to expand to the full width of the page, but can't because of the hack added, the lack of a right border on #content looks messed up, but you can't add one the same way vector adds the left one without a second content area inside the content area or using css3 multiple backgrounds that only work in some modern browsers. - What you really want sounds like an enhancement to vector to provide wrapper elements with a class that can be used to make the actual content+ui of vector fixed-width. I don't see a good enough reason to force users to migrate css breaking compatibility or maintain duplicate signatures. Please file the vector enhancements as a separate 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 12788] CSS (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=12788 Bug 12788 depends on bug 24915, which changed state. Bug 24915 Summary: Move CSS signatures from body to html https://bugzilla.wikimedia.org/show_bug.cgi?id=24915 What|Old Value |New Value Status|NEW |RESOLVED Resolution||WONTFIX -- 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 19719] HTML5 (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=19719 Bug 19719 depends on bug 24915, which changed state. Bug 24915 Summary: Move CSS signatures from body to html https://bugzilla.wikimedia.org/show_bug.cgi?id=24915 What|Old Value |New Value Status|NEW |RESOLVED Resolution||WONTFIX -- 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 30506] WebFonts should have not set any font explicitly prior to user selecting one from list
https://bugzilla.wikimedia.org/show_bug.cgi?id=30506 Santhosh Thottingal santhosh.thottin...@gmail.com changed: What|Removed |Added Priority|Unprioritized |Normal Severity|major |enhancement -- 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 31885] CheckUser WHOIS link broken
https://bugzilla.wikimedia.org/show_bug.cgi?id=31885 --- Comment #4 from John Du Hart j...@compwhizii.net 2011-10-26 14:23:45 UTC --- Although I love domain tools I would prefer something that's, uh, not meant to be profited from. Like the WHOIS tool on the toolserver. -- 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 31959] New: Accept multipart/form-data Content-Type for API Edit
https://bugzilla.wikimedia.org/show_bug.cgi?id=31959 Web browser: --- Bug #: 31959 Summary: Accept multipart/form-data Content-Type for API Edit Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Unprioritized Component: API AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: m8r-udf...@mailinator.com CC: bryan.tongm...@gmail.com, roan.katt...@gmail.com, s...@reedyboy.net, soxre...@gmail.com Classification: Unclassified The edit api should accept multipart/form-data rather than just application/x-www-form-urlencoded. The encoding of large articles can needlessly double the post, while also requiring additional encoding/decoding 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 31959] Accept multipart/form-data Content-Type for API Edit
https://bugzilla.wikimedia.org/show_bug.cgi?id=31959 --- Comment #1 from Roan Kattouw roan.katt...@gmail.com 2011-10-26 14:34:44 UTC --- Have you tried to see if it supports multipart/form-data now? This seems to be a PHP issue to me, not a MediaWiki issue per se. -- 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 31794] [Users.php] HTML5 \o/
https://bugzilla.wikimedia.org/show_bug.cgi?id=31794 --- Comment #4 from Chad H. innocentkil...@gmail.com 2011-10-26 14:35:09 UTC --- Copy in svn is borked, see http://svn.wikimedia.org/users2.php -- 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 31609] Option to change reCAPTCHA theme
https://bugzilla.wikimedia.org/show_bug.cgi?id=31609 John Du Hart j...@compwhizii.net changed: What|Removed |Added Status|NEW |RESOLVED CC||j...@compwhizii.net Resolution||FIXED --- Comment #1 from John Du Hart j...@compwhizii.net 2011-10-26 14:55:03 UTC --- Thank you very much for the patch, I've applied it with some changes in r100813. Just note that you can multiple global variables on one keyword and it's a good idea to escape JS strings. I hope to see another patch from you 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 31960] New: EXIF orientation is not taken in account
https://bugzilla.wikimedia.org/show_bug.cgi?id=31960 Web browser: --- Bug #: 31960 Summary: EXIF orientation is not taken in account Product: MediaWiki Version: 1.18 Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: Images and files AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: eugene.zele...@gmail.com CC: bawolff...@gmail.com, bryan.tongm...@gmail.com Classification: Unclassified Hi! I encountered issue with EXIF orientation on freshly uploaded image: http://commons.wikimedia.org/wiki/File:Royal_Military_College_of_Canada%27s_Currie_Hall.jpg. Eugene. -- 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 31467] Tracking bug for getting the Android app on translatewiki
https://bugzilla.wikimedia.org/show_bug.cgi?id=31467 John Du Hart j...@compwhizii.net changed: What|Removed |Added Keywords|patch | CC||j...@compwhizii.net --- Comment #8 from John Du Hart j...@compwhizii.net 2011-10-26 15:33:08 UTC --- -patch, no patch in sight. -- 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 31609] Option to change reCAPTCHA theme
https://bugzilla.wikimedia.org/show_bug.cgi?id=31609 John Du Hart j...@compwhizii.net changed: What|Removed |Added Keywords|need-review |reviewed -- 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 31467] Tracking bug for getting the Android app on translatewiki
https://bugzilla.wikimedia.org/show_bug.cgi?id=31467 --- Comment #9 from Tomasz Finc tf...@wikimedia.org 2011-10-26 15:36:11 UTC --- (In reply to comment #8) -patch, no patch in sight. What do you mean? We've already merged in brions patch for this. Now someone just needs to tackle the rest of the strings. -- 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 30783] mw.config.get and mw.config.set should allow additional calling patterns
https://bugzilla.wikimedia.org/show_bug.cgi?id=30783 John Du Hart j...@compwhizii.net changed: What|Removed |Added Attachment #9020|0 |1 is obsolete|| --- Comment #1 from John Du Hart j...@compwhizii.net 2011-10-26 15:36:40 UTC --- Created attachment 9285 -- https://bugzilla.wikimedia.org/attachment.cgi?id=9285 Patch Reattached as a patch -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 30783] mw.config.get and mw.config.set should allow additional calling patterns
https://bugzilla.wikimedia.org/show_bug.cgi?id=30783 John Du Hart j...@compwhizii.net changed: What|Removed |Added CC||j...@compwhizii.net --- Comment #2 from John Du Hart j...@compwhizii.net 2011-10-26 15:45:03 UTC --- Could you provide some sort of use case for this? RoanKattouw And I don't want get() to be a screenful of let's figure out which of the 23 calling conventions was used and what our params are followed by 5 lines of actual work Is also a concern, unless this is a huge step in some way for de-complexifying some piece of code, I would rather keep those methods simple. -- 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 29283] Localisation Cache ACCEL store
https://bugzilla.wikimedia.org/show_bug.cgi?id=29283 John Du Hart j...@compwhizii.net changed: What|Removed |Added Keywords|need-review |reviewed CC||j...@compwhizii.net --- Comment #5 from John Du Hart j...@compwhizii.net 2011-10-26 15:51:06 UTC --- -needs-review Per the above the diff isn't properly targetting a file and needs an Autoloader entry. Also if you could make it confirm to our Coding Conventions it would be appreciated. https://www.mediawiki.org/wiki/Manual:Coding_conventions Let me know on #mediawiki if you'd like some help :) +reviewed -- 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 31950] Need updated fonts for Malayalam in Server
https://bugzilla.wikimedia.org/show_bug.cgi?id=31950 --- Comment #2 from praveenp me.prav...@gmail.com 2011-10-26 15:53:48 UTC --- Like in rendering svg, easy time line, webfonts etc.. :) -- 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 31960] EXIF orientation is not taken in account
https://bugzilla.wikimedia.org/show_bug.cgi?id=31960 --- Comment #1 from Brion Vibber br...@wikimedia.org 2011-10-26 15:58:24 UTC --- This file has incorrect metadata; it's being rotated just as the metadata demands, and so ends up being rotated from landscape to portrait. The same thing happens opening the file in Mac OS X's Preview app or the Gimp photo editor. You'll need to fix the image and re-upload 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 31951] Intergrate Extension:Interwiki into mediawiki core
https://bugzilla.wikimedia.org/show_bug.cgi?id=31951 --- Comment #2 from Brion Vibber br...@wikimedia.org 2011-10-26 16:03:49 UTC --- I imagine the default case would probably be to not use any interwiki links at all; given also that we can bundle extensions with the distribution, I don't see much reason to integrate more such tools into core itself. -- 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 31959] Accept multipart/form-data Content-Type for API Edit
https://bugzilla.wikimedia.org/show_bug.cgi?id=31959 --- Comment #2 from Smallman m8r-udf...@mailinator.com 2011-10-26 16:06:32 UTC --- I just tried and it works! Will update API:Edit that large text files should be done via multipart as opposed to urlencoded. -- 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 31481] Android app should have 'Share' menu item to send to other apps (mail, notes, social networking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=31481 Patrick Reilly prei...@wikimedia.org changed: What|Removed |Added CC||prei...@wikimedia.org --- Comment #2 from Patrick Reilly prei...@wikimedia.org 2011-10-26 16:09:47 UTC --- (In reply to comment #1) This PhoneGap plugin should help: https://github.com/phonegap/phonegap-plugins/tree/master/Android/SoftKeyboard I think that we want: https://github.com/phonegap/phonegap-plugins/tree/master/Android/Share -- 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 31959] Accept multipart/form-data Content-Type for API Edit
https://bugzilla.wikimedia.org/show_bug.cgi?id=31959 Brion Vibber br...@wikimedia.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 31889] Include more Tamil webfonts
https://bugzilla.wikimedia.org/show_bug.cgi?id=31889 --- Comment #4 from Brion Vibber br...@wikimedia.org 2011-10-26 16:29:27 UTC --- What's the benefit of adding more fonts here? Are they supposed to be alternate selections for body text, or are they supposed to get mapped to some specific uses? In general simply adding more choices for body text probably isn't a good idea as it complicates things for little clear benefit. -- 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 31896] Installer on SVN trunk doesn't recognize mysql installer on fbsd
https://bugzilla.wikimedia.org/show_bug.cgi?id=31896 --- Comment #3 from Brion Vibber br...@wikimedia.org 2011-10-26 16:30:31 UTC --- So any directions on how to reproduce, such as the version of FreeBSD and how PHP and MySQL were installed? -- 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 31961] New: The qqx language cannot show names of messages used in JavaScripts
https://bugzilla.wikimedia.org/show_bug.cgi?id=31961 Web browser: --- Bug #: 31961 Summary: The qqx language cannot show names of messages used in JavaScripts Product: MediaWiki Version: (wikimedia-deployment) Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: Internationalization AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: liang...@gmail.com CC: niklas.laxst...@gmail.com, s.mazel...@xs4all.nl Classification: Unclassified http://en.wikipedia.org/wiki/0.999...?uselang=qqx The Rate this page panel doesn't get message-names-as-contents replacement. -- 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 31889] Include more Tamil webfonts
https://bugzilla.wikimedia.org/show_bug.cgi?id=31889 --- Comment #5 from Santhosh Thottingal santhosh.thottin...@gmail.com 2011-10-26 16:45:45 UTC --- (In reply to comment #4) What's the benefit of adding more fonts here? Are they supposed to be alternate selections for body text, or are they supposed to get mapped to some specific uses? In general simply adding more choices for body text probably isn't a good idea as it complicates things for little clear benefit. Each of them mapped to specific users and specific requirements for the language. Many languages have different fonts to address different writing styles, And there is a preference for certain writing style for users. For example, in Malayalam, there are 2 writing styles, one with vowel signs always forming a single glyph, and one with simplified writing style where vowel signs are always separate glyphs. That is the reason for the UI to allow users to select font according to their writing style. For Hebrew, there are fonts with diacritics marks and without them, and both of them are used according to user preference, Sometimes there are text, that must be shown with a specific font to illustrate something. -- 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 31961] The qqx language cannot show names of messages used in JavaScripts
https://bugzilla.wikimedia.org/show_bug.cgi?id=31961 --- Comment #1 from Niklas Laxström niklas.laxst...@gmail.com 2011-10-26 16:48:43 UTC --- Slippery slope. It takes more and more effort to get it work everywhere for diminishing returns. -- 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 31447] Tracking bug for 1.0 release of Android App
https://bugzilla.wikimedia.org/show_bug.cgi?id=31447 Tomasz Finc tf...@wikimedia.org changed: What|Removed |Added Blocks||31706 -- 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 31706] Android app should give up a page load if its been going for more then X amount of time
https://bugzilla.wikimedia.org/show_bug.cgi?id=31706 Tomasz Finc tf...@wikimedia.org changed: What|Removed |Added Depends on||31447 -- 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 31707] Android app only shows add bookmark and bookmarks on app load
https://bugzilla.wikimedia.org/show_bug.cgi?id=31707 Tomasz Finc tf...@wikimedia.org changed: What|Removed |Added Blocks||31447 Depends on|31447 | -- 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 31447] Tracking bug for 1.0 release of Android App
https://bugzilla.wikimedia.org/show_bug.cgi?id=31447 Tomasz Finc tf...@wikimedia.org changed: What|Removed |Added Blocks|31707 | Depends on||31707 -- 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 31705] Android app should not show a confirm bookmarks dialog
https://bugzilla.wikimedia.org/show_bug.cgi?id=31705 Tomasz Finc tf...@wikimedia.org changed: What|Removed |Added Blocks||31447 -- 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 31447] Tracking bug for 1.0 release of Android App
https://bugzilla.wikimedia.org/show_bug.cgi?id=31447 Tomasz Finc tf...@wikimedia.org changed: What|Removed |Added Depends on||31705 -- 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 31956] Android app nearby me should offer a list view
https://bugzilla.wikimedia.org/show_bug.cgi?id=31956 Mark A. Hershberger m...@everybody.org changed: What|Removed |Added CC||m...@everybody.org --- Comment #1 from Mark A. Hershberger m...@everybody.org 2011-10-26 17:10:14 UTC --- Also: http://meta.wikimedia.org/wiki/File:Wiki_0022_NearbyList_Options-Menu.png -- 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 31954] Android app should allow user to select another near by listing without hitting the hardware button
https://bugzilla.wikimedia.org/show_bug.cgi?id=31954 --- Comment #1 from Tomasz Finc tf...@wikimedia.org 2011-10-26 17:16:55 UTC --- What i'm thinking here is that a user shouldn't have to navigate backwards to select another already present pin on the map. If we have 10 location on the map. Then i shouldn't have to 1) Select pin #1 2) Hit the back button 3) Select pin #2 I should just be able to do step #1 and #3. This will prep us well when we eventually talk about tablets that can display lots of pins. On tables step #2 will be a waste of time. -- 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 31613] API UsageException when saving a collection to a page
https://bugzilla.wikimedia.org/show_bug.cgi?id=31613 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added CC||roan.katt...@gmail.com --- Comment #5 from Roan Kattouw roan.katt...@gmail.com 2011-10-26 17:58:07 UTC --- It's not hashed with the entire request. $request is just passed through so that getEditToken() can do $token = $request-getSessionData( 'wsEditToken' ); (line 3194) It's very unlikely that there is a logic error in matchEditToken(), or there'd be a heck of a lot more things breaking. -- 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 31958] Enable per-page (e.g. by means of a tag on the page) Mediawiki-namespace-based javascript inclusion
https://bugzilla.wikimedia.org/show_bug.cgi?id=31958 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added CC||roan.katt...@gmail.com --- Comment #1 from Roan Kattouw roan.katt...@gmail.com 2011-10-26 17:59:41 UTC --- Why would you want per-page JS? What kind of use case does this address that Gadgets doesn't already address? -- 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 31613] API UsageException when saving a collection to a page
https://bugzilla.wikimedia.org/show_bug.cgi?id=31613 Mark A. Hershberger m...@everybody.org changed: What|Removed |Added Priority|Normal |Highest --- Comment #6 from Mark A. Hershberger m...@everybody.org 2011-10-26 17:59:55 UTC --- Bumping priority since it was seen in Bug 31821 -- 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 31821] Special:Book not allowing saving
https://bugzilla.wikimedia.org/show_bug.cgi?id=31821 Mark A. Hershberger m...@everybody.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #5 from Mark A. Hershberger m...@everybody.org 2011-10-26 18:01:13 UTC --- (In reply to comment #4) AFIK this is a bug in the API that was already documented in bug 31613 Looks like it. Bumped priority of bug 31613, re-closing this one. -- 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 31259] Large numbers are rendered differently depending on which server is rendering them
https://bugzilla.wikimedia.org/show_bug.cgi?id=31259 Mark A. Hershberger m...@everybody.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #16 from Mark A. Hershberger m...@everybody.org 2011-10-26 18:52:49 UTC --- (In reply to comment #15) Yes! This is fixed. Closing. -- 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 31885] CheckUser WHOIS link broken
https://bugzilla.wikimedia.org/show_bug.cgi?id=31885 --- Comment #5 from Mark A. Hershberger m...@everybody.org 2011-10-26 19:08:02 UTC --- or a PHP implementation of WHOIS? http://pear.php.net/package/Net_Whois for example: $ pear install Net_Whois $ php -r 'require (Net/Whois.php);$w = new Net_Whois();echo $w-query(n 46.105.138.12);' results in: # # The following results may also be obtained via: # http://whois.arin.net/rest/nets;q=46.105.138.12?showDetails=trueshowARIN=falseext=netref2 # NetRange: 46.0.0.0 - 46.255.255.255 CIDR: 46.0.0.0/8 OriginAS: NetName:46-RIPE NetHandle: NET-46-0-0-0-0 Parent: NetType:Allocated to RIPE NCC Comment:These addresses have been further assigned to users in Comment:the RIPE NCC region. Contact information can be found in Comment:the RIPE database at http://www.ripe.net/whois RegDate:2009-09-29 Updated:2009-09-30 Ref:http://whois.arin.net/rest/net/NET-46-0-0-0-0 OrgName:RIPE Network Coordination Centre OrgId: RIPE Address:P.O. Box 10096 City: Amsterdam StateProv: PostalCode: 1001EB Country:NL RegDate: Updated:2011-09-24 Ref:http://whois.arin.net/rest/org/RIPE ReferralServer: whois://whois.ripe.net:43 OrgAbuseHandle: RNO29-ARIN OrgAbuseName: RIPE NCC Operations OrgAbusePhone: +31 20 535 OrgAbuseEmail: hostmas...@ripe.net OrgAbuseRef:http://whois.arin.net/rest/poc/RNO29-ARIN OrgTechHandle: RNO29-ARIN OrgTechName: RIPE NCC Operations OrgTechPhone: +31 20 535 OrgTechEmail: hostmas...@ripe.net OrgTechRef:http://whois.arin.net/rest/poc/RNO29-ARIN # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/whois_tou.html # % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf %ERROR:101: no entries found % % No entries found in the selected source(s). -- 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 31885] CheckUser WHOIS link broken
https://bugzilla.wikimedia.org/show_bug.cgi?id=31885 --- Comment #6 from Mark A. Hershberger m...@everybody.org 2011-10-26 19:15:06 UTC --- Avoiding n before the IP is better since $w-query(46.105.138.12): # # Query terms are ambiguous. The query is assumed to be: # n 46.105.138.12 # # Use ? to get help. # # # The following results may also be obtained via: # http://whois.arin.net/rest/nets;q=46.105.138.12?showDetails=trueshowARIN=falseext=netref2 # NetRange: 46.0.0.0 - 46.255.255.255 CIDR: 46.0.0.0/8 OriginAS: NetName:46-RIPE NetHandle: NET-46-0-0-0-0 Parent: NetType:Allocated to RIPE NCC Comment:These addresses have been further assigned to users in Comment:the RIPE NCC region. Contact information can be found in Comment:the RIPE database at http://www.ripe.net/whois RegDate:2009-09-29 Updated:2009-09-30 Ref:http://whois.arin.net/rest/net/NET-46-0-0-0-0 OrgName:RIPE Network Coordination Centre OrgId: RIPE Address:P.O. Box 10096 City: Amsterdam StateProv: PostalCode: 1001EB Country:NL RegDate: Updated:2011-09-24 Ref:http://whois.arin.net/rest/org/RIPE ReferralServer: whois://whois.ripe.net:43 OrgAbuseHandle: RNO29-ARIN OrgAbuseName: RIPE NCC Operations OrgAbusePhone: +31 20 535 OrgAbuseEmail: hostmas...@ripe.net OrgAbuseRef:http://whois.arin.net/rest/poc/RNO29-ARIN OrgTechHandle: RNO29-ARIN OrgTechName: RIPE NCC Operations OrgTechPhone: +31 20 535 OrgTechEmail: hostmas...@ripe.net OrgTechRef:http://whois.arin.net/rest/poc/RNO29-ARIN # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/whois_tou.html # % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the -B flag. % Information related to '46.105.138.0 - 46.105.138.15' inetnum: 46.105.138.0 - 46.105.138.15 netname: HexxehNET descr: Hexxeh.net country: GB org: ORG-OL17-RIPE admin-c: OTC14-RIPE tech-c: OTC14-RIPE status: ASSIGNED PA mnt-by: OVH-MNT source: RIPE # Filtered organisation: ORG-OL17-RIPE org-name: OVH Ltd org-type: OTHER address:3 Southwark street address:LONDON SE1 1RQ address:UK abuse-mailbox: ab...@ovh.net admin-c:OTC2-RIPE mnt-ref:OVH-MNT mnt-by: OVH-MNT source: RIPE # Filtered role: OVH UK Technical Contact address:OVH Ltd address:3 Southwark street address:LONDON SE1 1RQ address:UK admin-c:OK217-RIPE tech-c: GM84-RIPE nic-hdl:OTC14-RIPE abuse-mailbox: ab...@ovh.net mnt-by: OVH-MNT source: RIPE # Filtered % Information related to '46.105.0.0/16AS16276' route: 46.105.0.0/16 descr: OVH ISP descr: Paris, France origin: AS16276 mnt-by: OVH-MNT source: RIPE # Filtered -- 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 31613] API UsageException when saving a collection to a page
https://bugzilla.wikimedia.org/show_bug.cgi?id=31613 --- Comment #7 from Christoph Kepper christoph.kep...@pediapress.com 2011-10-26 19:21:30 UTC --- You are right Roan. This is not the problem. After digging a little deeper I found that the $request parameter that is handed to matchEditToken() is the FauxRequest. This FauxRequest does not contain 'wsEditToken' and so getEditToken() generates a new token with every call. I don't know what would be the right way to fix this. It works if I set $request = null in matchEditToken() but this seems like short-circuiting the check. -- 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 31865] Tag dws for discarding whitespaces.
https://bugzilla.wikimedia.org/show_bug.cgi?id=31865 Mark A. Hershberger m...@everybody.org changed: What|Removed |Added Keywords||need-review, parser, ||parsertest, patch Priority|Unprioritized |Normal CC||m...@everybody.org --- Comment #4 from Mark A. Hershberger m...@everybody.org 2011-10-26 19:22:26 UTC --- (In reply to comment #3) Sorry, I know I shouldn't use the issue tracker for discussion, but I just did. As long as the discussion is directly relevant to the original issue, discussion is fine. Now to make my discussion ok: (In reply to comment #1) This is implementation of the tag dws. To get this applied could you please supply some parser tests? -- 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
