[Bug 13151] Transfer some Features from DPL to ask
https://bugzilla.wikimedia.org/show_bug.cgi?id=13151 fastgoldf...@gmail.com changed: What|Removed |Added CC||fastgoldf...@gmail.com --- Comment #6 from fastgoldf...@gmail.com 2011-07-20 06:40:06 UTC --- Here's some more ideas: http://smw.referata.com/wiki/Add_page_metadata_properties_to_a_page_(using_DPL) Having access to page metadata via SMW opens up very exciting possibilities. Part of the struggle with creating a useful semantic wiki is in managing the data. Being able to examine a wiki semantically would be a very power tool for finding out what's in your wiki (and what might be missing). Just today, the thought crossed my mind that I would like to be able to find out what templates are being used on pages with certain properties. That would make it easy for me to reduce complexity by reducing the number of templates I'm using. There's really an enormous amount of power and flexibility that can be offered with semantic metadata. I look forward to seeing these features. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 491] Categories need piping feature to list by alternative name
https://bugzilla.wikimedia.org/show_bug.cgi?id=491 Niklas Laxström niklas.laxst...@gmail.com changed: What|Removed |Added Depends on||29975 -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 29975] New: Provide a way to alter page titles in category listings
https://bugzilla.wikimedia.org/show_bug.cgi?id=29975 Web browser: --- Bug #: 29975 Summary: Provide a way to alter page titles in category listings Product: MediaWiki Version: 1.19-svn Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: Categories AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: niklas.laxst...@gmail.com Blocks: 491, 29928 Classification: Unclassified There should be a way to not use the actual page titles but something else instead in the category listing. Would be useful for example translated titles. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 29928] show translated titles per user language
https://bugzilla.wikimedia.org/show_bug.cgi?id=29928 Niklas Laxström niklas.laxst...@gmail.com changed: What|Removed |Added Depends on||29975 -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 29976] New: protocol relative uri for meta edituri
https://bugzilla.wikimedia.org/show_bug.cgi?id=29976 Web browser: --- Bug #: 29976 Summary: protocol relative uri for meta edituri Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: General/Unknown AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: hart...@videolan.org Classification: Unclassified Test shows: link rel=EditURI type=application/rsd+xml href=https://secure.wikimedia.org/wikipedia/test/w/api.php?action=rsd; / -- 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 29976] protocol relative uri for meta edituri
https://bugzilla.wikimedia.org/show_bug.cgi?id=29976 Bryan Tong Minh bryan.tongm...@gmail.com changed: What|Removed |Added CC||bryan.tongm...@gmail.com, ||roan.katt...@gmail.com, ||s...@reedyboy.net, ||soxre...@gmail.com, ||vasi...@gmail.com Component|General/Unknown |API --- Comment #1 from Bryan Tong Minh bryan.tongm...@gmail.com 2011-07-20 07:41:41 UTC --- Putting this in the API component, even though this is in the HTML output of index.php, as it refers to an API module. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 29967] Better support for viewing and downloading large files
https://bugzilla.wikimedia.org/show_bug.cgi?id=29967 --- Comment #3 from Bryan Tong Minh bryan.tongm...@gmail.com 2011-07-20 07:45:33 UTC --- We could go even one step further, and add this little information box to *all* our thumbs, also those embedded in articles, with a box like: * View author, license and other file information * Downloads scaled down version ** 800x600 pixels ** 1024x768 pixels ** 2048x1536 pixels * Download full version (2x2000 pixels; 10 gazillion bytes) That might be controversial though. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 29977] New: Description url in imageinfo ouputs protocol relative urls
https://bugzilla.wikimedia.org/show_bug.cgi?id=29977 Web browser: --- Bug #: 29977 Summary: Description url in imageinfo ouputs protocol relative urls Product: MediaWiki Version: unspecified Platform: All URL: https://test.wikipedia.org/w/api.php?action=querygene rator=allimagesgailimit=4gaifrom=Tprop=imageinfoii prop=url OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: API AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: bryan.tongm...@gmail.com CC: bryan.tongm...@gmail.com, roan.katt...@gmail.com, s...@reedyboy.net, soxre...@gmail.com, vasi...@gmail.com Classification: Unclassified See attached url, while the url result is protocol absolute, the description url is protocol relative. -- 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 29894] Messages defined in MediaWiki namespace are not always used again
https://bugzilla.wikimedia.org/show_bug.cgi?id=29894 --- Comment #2 from Liangent liang...@gmail.com 2011-07-20 08:17:41 UTC --- I would say it's unstable. Sometimes this problem appears (not very often) and disappears 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 164] Support collation by a certain locale (sorting order of characters)
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #218 from Philippe Verdy verd...@wanadoo.fr 2011-07-20 08:54:53
UTC ---
OK, I immediately found a bug in the binary search function (which is defintely
not beinary, has slower than expected convergence, and may even stale on
testing the same index, due to incorrect handling of min/max indice after
comparing):
291 function findLowerBound( $valueCallback, $valueCount,
$comparisonCallback, $target ) {
292$min = 0;
293$max = $valueCount - 1;
294do {
295$mid = $min + ( ( $max - $min ) 1 );
296$item = call_user_func( $valueCallback, $mid );
297$comparison = call_user_func(
$comparisonCallback, $target, $item );
298if ( $comparison 0 ) {
299$min = $mid;
300} elseif ( $comparison == 0 ) {
301$min = $mid;
302break;
303} else {
304$max = $mid;
305}
306} while ( $min $max - 1 );
307
308if ( $min == 0 $max == 0 $comparison 0 ) {
309// Before the first item
310return false;
311} else {
312return $min;
313}
314}
The authout should have better read how TESTED binary searches are implemented.
This should really be:
function findLowerBound( $valueCallback, $valueCount, $comparisonCallback,
$target ) {
$min = 0;
$max = $valueCount - 1;
while ( $min = $max ) {
$mid = ($min + $max) 1;
$item = call_user_func( $valueCallback, $mid );
$comparison = call_user_func( $comparisonCallback, $item, $target
);
if ( $comparison 0 ) {
$min = $mid + 1;
} elseif ( $comparison 0 ) {
$max = $mid - 1;
} else {
return $mid; // or: $max = $mid; break;
}
}
// $target not found, now $max min (more exactly, $max = $min - 1).
// $target is to insert between them: $max is the highest lower bound.
if ( $max 0 ) {
// Before the first item
return false; // Don't test with a simple if !
} else {
return $max; // May return 0 (lower bound on first item)
}
}
Note that the final test to return false is unnecessary and causes confusion on
usage (if you had written this in C/C++ instead of PHP, you would not be able
to make the distinction between false (no lower bound not found) and 0 (valid
lower bound). Your code should not depend on those PHP hacks, which consists in
returning values of distinct types (but with PHP's implicit promotion on basic
types, it's really dangerous do do that) !
It's just simpler to let it return -1 (the content already in $max when we are
before the first item), and then let the caller test the negative sign of the
result, instead of comparing it then with false.
--
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 29971] Set wgUploadMissingFileUrl for nlwiki
https://bugzilla.wikimedia.org/show_bug.cgi?id=29971 Reedy s...@reedyboy.net changed: What|Removed |Added Keywords|ops |shell -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 29958] SQL Error generated from includes/parser/LinkHolderArray.php (namespace not quoted)
https://bugzilla.wikimedia.org/show_bug.cgi?id=29958 --- Comment #5 from Andrew Berridge andrew.berri...@gmail.com 2011-07-20 10:00:24 UTC --- Hi Yaron, I see that my links have been obfuscated above. 0 or 1 need to be substituted with r5, but I think you know that from our previous discussions! I have upgraded to 2.2. It doesn't fix the issue. If it helps, I am able to open a page with this error for edit but saved changes do not take effect. More info: The overarching category uses Has default form, but when I go to a page and Edit With Form, I get: Warning: This page already exists, but it does not use this form. This didn't happen previously! Any ideas where I could look for the variable substitution for the Namespace? I want to help fix this issue. Thanks, Andrew -- 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 29958] SQL Error generated from includes/parser/LinkHolderArray.php (namespace not quoted)
https://bugzilla.wikimedia.org/show_bug.cgi?id=29958 --- Comment #6 from Andrew Berridge andrew.berri...@gmail.com 2011-07-20 10:06:53 UTC --- Eeek! Something's not right with the Forms namespace elsewhere too... Going to Special:Forms shows an empty namespace. Of course, it doesn't help that one of my users has accidentally overwritten the Form with some text. The old text of the form doesn't show up in the history, so I may have to create it from scratch. The forms show as: :Car Record (for example). Andrew -- 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 29978] New: Textarea tag with autocomplete doesn't close
https://bugzilla.wikimedia.org/show_bug.cgi?id=29978
Web browser: ---
Bug #: 29978
Summary: Textarea tag with autocomplete doesn't close
Product: MediaWiki extensions
Version: any
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: Unprioritized
Component: SemanticForms
AssignedTo: yaro...@gmail.com
ReportedBy: pe...@gridline.nl
CC: wikibugs-l@lists.wikimedia.org
Classification: Unclassified
I have a form with two autocomplete textareas. Editing pages works without a
problem, but when creating a new page the textarea tag isn't closed and the
rest of the page html is interpreted by the browser as the content of the
textarea.
This problem popped up when I upgraded to SF 2.2 and M 1.17. The problem
doesn't happen on the acceptance server, which was upgraded to MW 1.16 and
probably a lower version of SF 2.1 (I can't check at the moment).
I did some digging and tracked the problem down to line 1087 of
SF_FormInputs.php where the textarea element is created:
$textarea_input = Xml::element('textarea', $textarea_attrs, $cur_value,
false);
Apparently, when the $cur_value param is null, the Xml::element renders a start
tag only. When I change the line to
$textarea_input = Xml::element('textarea', $textarea_attrs, $cur_value. ,
false);
the problem disappears.
--
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 29978] Textarea tag with autocomplete doesn't close
https://bugzilla.wikimedia.org/show_bug.cgi?id=29978 Niklas Laxström niklas.laxst...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||niklas.laxst...@gmail.com Resolution||WORKSFORME --- Comment #1 from Niklas Laxström niklas.laxst...@gmail.com 2011-07-20 10:23:54 UTC --- Cast it into a string or use Html::element. Xml::element has that ugly behavior but there isn't much we can do about it except provide an better alternative. -- 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 164] Support collation by a certain locale (sorting order of characters)
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #219 from Philippe Verdy verd...@wanadoo.fr 2011-07-20 11:20:08
UTC ---
I note the following comment in r80443:
* Changed Title::getCategorySortkey() to separate its parts with a line break
instead of a null character. All collations supported by the intl extension
ignore the null character, i.e. ab == a\0b. It would have required a lot of
hacking to make it work.
If you had read my comments above, I had already spoken since long about the
choice of the separator to use between the prefix and the rest of the full page
name: this had to be a non-ignorable character, that is clearly lower than any
character usable in the full pagename.
I had also stated which character to use, namely the TAB character that is the
first non-ignorable (i.e. with non-all-zeroes weights). See my Comment #190 for
the rationale (one year ago, much longer before your recent fix to use LF,
because before yu had tried with NULL, which was wrong, and even without any
separator which was also wrong).
You could have avoided these bugs, as I had analyzed it long before.
OK, LF (U+000A) is OK (because it is not allowed in full page names), even it
is not the first one.
---
One word for performance and space: you have put too many fields in table
categorylinks. Only one essential think is needed there for referencial
constraints and counting: the UNIQUE index on (cl_from, cl_to), which is
architectural. As this index is unique, it should share the same store as the
table itself. But SQL engines will never use more than one index per table to
read it, because it requires additional random-access cursors to access the
table. As the current unique index uses less fields than the table, it
implicitly creates a random-access reference from this index to the table
(basically, using internal rowids stored in the index, instead of reading
directly from the table).
To avoid this problem, you have to make sure that the table is formatted so
that its first fields match exactly the same order as the unique index. This is
the case for the first unique index created just after that. So the table and
the index share the same store, however the number of rows in the index per
storage page will be limited (the table can use up to 1KB per row, this does
not give a very compact and fast search in the index, as it will load too many
storage pages in memory, even when using a very selective search).
You may optimize searches (at the price of storage space), by indicating that
the unique index should still use a separate store. Normally this is the role
of the specifier PRIMARY which indicates to not use a separate store (it is
still UNIQUE). For now you don't have any PRIMARY index, only a UNIQUE index
which only uses a separate index store.
Now comes the two main kind of requests performed by MediaWiki:
(1) getting the list of categories in which a page is currently listed
(including when saving a page because this list must be flushed out and
replaced by the categories found when parsing the page). Ideally, this should
require at least an index on the cl_from. The UNIQUE index on (cl_from,cl_to)
works perfectly there because it is in separate store. Other attributes in the
table will not even be read, unless the SQL query wants to get these attributes
(if this is the case, both the index and table store will be read, the index
being read very rapidly and joined with the table using the internal table row
id, stored in the index with the two keys). In all what I have seen in the
MediaWiki code, this does not occur (including when rendering a page, to
display the list of categories, it just needs this list but gets it from the
page's wiki code parsing before saving it, and this gets saved in the page
cache).
(2) getting the list of pages in a category. There you need to use collation as
well because this list is sorted. Ideally, this should use an index and table
that just contain the necessary fields, and that the SQL SORT BY clause will
use those same fields, in the same order (and either all in ASCENDING, or all
in DESCENDING order). This is the second index:
CREATE INDEX /*i*/cl_sortkey ON /*_*/categorylinks (cl_to, cl_type, cl_sortkey,
cl_from);
Obviously, it cannot use the same index store as the table. The introduction of
the cl_type field is recent. It supposes that you will be paging the category
views by page type, in the order set by cl_type, which is:
ENUM ('page', 'subcat', 'file').
I wonder if this is correct and if it's the expected order. But anyway this
design means that the current code will actually perform three separate
requests, each one will be paged separately: one request to get the list of
normal pages, another to get the list of subcats, and another to get the list
of files. This will be inefficient, and hard to manage for the paging, unless
these three types can be effectively paged separately in the MediaWiki HTML UI
(this is not the case, as of today).
[Bug 29979] New: LinkCache::addLinkObj Database returned error 1205: Lock wait timeout exceeded; try restarting transaction
https://bugzilla.wikimedia.org/show_bug.cgi?id=29979 Web browser: --- Bug #: 29979 Summary: LinkCache::addLinkObj Database returned error 1205: Lock wait timeout exceeded; try restarting transaction Product: MediaWiki Version: 1.16.0 Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: Database AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: s...@reedyboy.net Blocks: 28499 Classification: Unclassified A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function LinkCache::addLinkObj. Database returned error 1205: Lock wait timeout exceeded; try restarting transaction Reported in 1.16, but could still be prevalent in 1.17 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 28499] 1205: Lock wait timeout exceeded; try restarting transaction (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=28499 Reedy s...@reedyboy.net changed: What|Removed |Added Depends on||29979 -- 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 12872] Add variable to show the topmost level in the tree of subpages
https://bugzilla.wikimedia.org/show_bug.cgi?id=12872
mybugs.m...@gmail.com changed:
What|Removed |Added
CC||mybugs.m...@gmail.com
--- Comment #17 from mybugs.m...@gmail.com 2011-07-20 12:00:12 UTC ---
See also:
* [[Extension:BookManager#Variables]]
** {{ROOTPAGENAME}}
** {{ROOTPAGENAMEE}}
* [[Template:ROOTPAGENAME]]
--
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 29979] LinkCache::addLinkObj Database returned error 1205: Lock wait timeout exceeded; try restarting transaction
https://bugzilla.wikimedia.org/show_bug.cgi?id=29979 --- Comment #1 from Reedy s...@reedyboy.net 2011-07-20 12:01:11 UTC --- SELECT page_id,page_len,page_is_redirect FROM `ec_page` WHERE page_namespace = '10' AND page_title = 'Infobox/NPC/Ultima_II' LIMIT 1 FOR UPDATE -- 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 12872] Add variable to show the topmost level in the tree of subpages
https://bugzilla.wikimedia.org/show_bug.cgi?id=12872 --- Comment #18 from mybugs.m...@gmail.com 2011-07-20 12:01:24 UTC --- (In reply to comment #17) * [[Extension:BookManager#Variables]] Uops... I mean [[mw:Extension:BookManager#Variables]]. -- 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 164] Support collation by a certain locale (sorting order of characters)
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #220 from Tim Starling tstarl...@wikimedia.org 2011-07-20
12:14:54 UTC ---
(In reply to comment #218)
if ( $comparison 0 ) {
$min = $mid + 1;
} elseif ( $comparison 0 ) {
$max = $mid - 1;
The function is not a classical binary search, which only determines equality,
instead it finds the lower bound of a range. When the test item sorts below the
target ($comparison 0), it can't be ruled out as a prospective lower bound.
That's why you need $min = $mid, not $min = $mid + 1.
Maybe $max = $mid - 1 is possible in the $comparison 0 case, with your
suggested alteration to the test for the before-the-start case. But the
existing code is tested and does work, and the improvement in convergence rate
would be small.
OK, I immediately found a bug in the binary search function (which is
defintely
not beinary, has slower than expected convergence, and may even stale on
testing the same index, due to incorrect handling of min/max indice after
comparing):
I assume by stale you mean an infinite loop. This does not occur because the
midpoint is always different from either of the two endpoints until the
difference $max - $min is reduced to 1 or 0, at which point the loop exits.
In a textbook binary search, offsetting the midpoint by 1 allows the loop to
continue until $min $max. But as I said, we can't offset the midpoint in the
$comparison 0 case, so a slightly earlier loop termination is required to
avoid an infinite loop.
Note that the final test to return false is unnecessary and causes confusion
on
usage (if you had written this in C/C++ instead of PHP, you would not be able
to make the distinction between false (no lower bound not found) and 0 (valid
lower bound). Your code should not depend on those PHP hacks, which consists
in
returning values of distinct types (but with PHP's implicit promotion on basic
types, it's really dangerous do do that) !
It's just simpler to let it return -1 (the content already in $max when we are
before the first item), and then let the caller test the negative sign of the
result, instead of comparing it then with false.
It's conventional for PHP functions to return false to indicate an error or
other unusual situation, see for instance http://php.net/array_search . It's
not at all dangerous. If I wrote the function in C, I would indeed have used
-1, and I would have called it an ugly hack to work around C's lack of weak
typing.
If you're aware of some actual bug in findLowerBound(), you should file a
separate bug report, or note it on
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/80443
--
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 29958] SQL Error generated from includes/parser/LinkHolderArray.php (namespace not quoted)
https://bugzilla.wikimedia.org/show_bug.cgi?id=29958 --- Comment #7 from Andrew Berridge andrew.berri...@gmail.com 2011-07-20 12:31:50 UTC --- Hi Yaron, Further to my comments above, I have done some more investigation. The example code: print NS_FORM: . SF_NS_FORM, shows NS_FORM:106 And: in specials/SF_Forms.php, function formatResult: $title = Title::makeTitle(SF_NS_FORM, $result-value ); $title becomes :Form_Name - no namespace. It's like the translation from 106 to Forms is not working. I will continue my investigations when I have time. Thanks, Andrew -- 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 164] Support collation by a certain locale (sorting order of characters)
https://bugzilla.wikimedia.org/show_bug.cgi?id=164 Domas Mituzas domas.mitu...@gmail.com changed: What|Removed |Added CC||domas.mitu...@gmail.com --- Comment #221 from Domas Mituzas domas.mitu...@gmail.com 2011-07-20 12:40:40 UTC --- @Philippe, InnoDB treats first UNIQUE index as clustered PRIMARY key, which stores all data with it (I assume you don't come from InnoDB background, please correct me otherwise ;-) cl_sortkey structure allows having dataset split by type (e.g. subcategories first, files last, whatever), and still maintain decent sorted order. cl_from is included for cases where we need to page over multiple entries with same sortkey. do note, as secondary keys would include primary key values anyway, it is not much of a cost. Back in the day both major reads used to be covering ones, without random lookups, I'm not sure if there's a regression nowadays with all the new collation code though. -- 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 29980] New: user email broken after upgrade from MW1.16.5 to MW1.17.0
https://bugzilla.wikimedia.org/show_bug.cgi?id=29980 Web browser: --- Bug #: 29980 Summary: user email broken after upgrade from MW1.16.5 to MW1.17.0 Product: MediaWiki Version: 1.17.0 Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: Email AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: deurnew...@gmail.com Classification: Unclassified I recently upgraded mediawiki of site www.DeurneWiki.nl from MW 1.16.5 to MW1.17.0. After upgrade the user e-mail function did not work anymore. The message you get when emailing is: SAFE MODE Restriction in effect. The fifth parameter is disabled in SAFE MODE Now, I know this is related to php being in safe mode, this however worked ok in MW 1.16.5 also with PHP in safe mode. hence: something has been broken... Joost de Haan (SysOp DeurneWiki) -- 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 29980] user email broken after upgrade from MW1.16.5 to MW1.17.0
https://bugzilla.wikimedia.org/show_bug.cgi?id=29980 --- Comment #1 from gjtokkel deurnew...@gmail.com 2011-07-20 12:58:51 UTC --- introduced in https://bugzilla.wikimedia.org/show_bug.cgi?id=27862 ? -- 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 25377] When a user gets renamed, it should be renamed too in the history/logs of the extension
https://bugzilla.wikimedia.org/show_bug.cgi?id=25377 Thomas Goldammer tho...@googlemail.com changed: What|Removed |Added CC||tho...@googlemail.com --- Comment #2 from Thomas Goldammer tho...@googlemail.com 2011-07-20 13:14:44 UTC --- I want to add that a search for the old username does not give any results with the log, despite the fact that the old username does still appear in the log (you get there only by searching for the *new* username which does in fact *not* appear in the log). It's very confusing. :) Best regards. -- 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. You are the assignee for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 164] Support collation by a certain locale (sorting order of characters)
https://bugzilla.wikimedia.org/show_bug.cgi?id=164 --- Comment #222 from Philippe Verdy verd...@wanadoo.fr 2011-07-20 13:18:31 UTC --- You should know that a binary search for equality of for lower bound is completely the same algorithm. (If not convined, look at the source of a C++ standard library, which uses the same function for both: finding exact matches or finding a lower bound for inserting a new item). The difference only occurs at end of the loop, about what you return when an exact equality is not found. In both cases, the binary search loop will terminate with min=max+1 exactly if no exact match is found, so that max is the lower bound you want. My suggestion fixes a few things: - it uses a while()... instead of a do...while() which is incorrect for the case where the search space opperates with count2. - it has faster convergence - it contains no special case to handle (your code will be erroneous in those cases). - even when searching with count=0, it starts with min=0 and max=-1, which terminates the loop immediately, with the same condition for not found (max min, and max if the lower bound) - it works with count=1 without creating an infinite loop like in your code when the target is higher that the only element [0] to check, because it ensures that the loop will ALWAYS reduce the search space at each interation. -- 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 29928] show translated titles per user language
https://bugzilla.wikimedia.org/show_bug.cgi?id=29928 --- Comment #4 from Rd232 rd...@hotmail.com 2011-07-20 13:22:26 UTC --- I meant interlanguage links. Sorry for the confusion. -- 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 29981] New: Clicking link to secure site takes me to insecure site
https://bugzilla.wikimedia.org/show_bug.cgi?id=29981 Web browser: --- Bug #: 29981 Summary: Clicking link to secure site takes me to insecure site Product: Wikimedia Version: unspecified Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: Unprioritized Component: SSL related AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: suma...@panix.com Classification: Unclassified On office.wikimedia.org, if I'm on the unsecure site http://office.wikimedia.org/wiki/Main_Page and then click on the banner link to https://office.wikimedia.org/ , I get directed to http://office.wikimedia.org/wiki/Main_Page I'm on Firefox 3.6.18. Installed extensions: Ubuntu Firefox Modifications 0.9rc2 HTTPS-Everywhere 0.9.7 Readability 1.9 Universal Print 0.4.24 -- 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 164] Support collation by a certain locale (sorting order of characters)
https://bugzilla.wikimedia.org/show_bug.cgi?id=164 --- Comment #223 from Philippe Verdy verd...@wanadoo.fr 2011-07-20 13:35:21 UTC --- The function is not a classical binary search, which only determines equality, instead it finds the lower bound of a range. When the test item sorts below the target ($comparison 0), it can't be ruled out as a prospective lower bound. And here you're completely wrong : in that case the comparison says that the mid idem is certainly not the lower bound. Don't forget that the item at max (and below) will also be tested: max will decrease as well, up to the point that it will either find an exact match, or will fall 1 position below min. That's why you need $min = $mid, not $min = $mid + 1. That's why you don't need that ! -- 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 29982] New: Enable [[mw:Extension:FlaggedRevs]] on ptwikibooks
https://bugzilla.wikimedia.org/show_bug.cgi?id=29982 Web browser: --- Bug #: 29982 Summary: Enable [[mw:Extension:FlaggedRevs]] on ptwikibooks Product: Wikimedia Version: unspecified Platform: All URL: https://secure.wikimedia.org/wikibooks/pt/wiki/Thread: Wikilivros:Diálogos_comunitários/Proposta:_Ativar_a_Ex tensão:ReaderFeedback/resposta_(7)?uselang=en OS/Version: All Status: NEW Keywords: shell Severity: normal Priority: Unprioritized Component: Extension setup AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: mybugs.m...@gmail.com Classification: Unclassified Per discussion on our local village pump, [[pt:b:Tópico:Wikilivros:Diálogos comunitários/Proposta: Ativar a Extensão:ReaderFeedback/resposta (7)]] please install FlaggedRevs extension on Portuguese Wikibooks with the following configuration: --- // Sets the most recent version as shown $wgFlaggedRevsOverride = false; $wgFlaggedRevsNamespaces = array( NS_MAIN, NS_TEMPLATE, NS_HELP, NS_PROJECT); $wgSimpleFlaggedRevsUI = false; $wgFlaggedRevComments = false; $wgFlaggedRevsAutopromote = array( 'days' = 30, # days since registration 'edits' = 100, # total edit count 'excludeDeleted' = true, # exclude deleted edits from 'edits' count above? 'spacing' = 2, # spacing of edit intervals 'benchmarks' = 8, # how many edit intervals are needed? 'recentContentEdits' = 5, # $wgContentNamespaces edits in recent changes 'totalContentEdits' = 50, # $wgContentNamespaces edits 'uniqueContentPages' = 10, # $wgContentNamespaces unique pages edited 'editComments' = 50, # how many edit comments used? 'email' = true, # user must be emailconfirmed? 'userpage' = false, # user must have a userpage? 'uniqueIPAddress' = false, # If $wgPutIPinRC is true, users sharing IPs won't be promoted 'neverBlocked' = true, # Can users that were blocked be promoted? ) + $wgFlaggedRevsAutopromote; $wgGroupPermissions['editor']['rollback'] = true; $wgGroupPermissions['sysop']['review'] = true; $wgGroupPermissions['sysop']['stablesettings'] = true; $wgGroupPermissions['sysop']['validate'] = true; --- Some notes: * Since our files are being migrated to Wikimedia Commons, NS_FILE was not included on wgFlaggedRevsNamespaces. * The other values defined above are the same currently used by English Wikibooks (see [[b:Wikibooks:FlaggedRevs Extension]]). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 29648] Set $wgCollectionHierarchyDelimiter = / for Wikibooks projects
https://bugzilla.wikimedia.org/show_bug.cgi?id=29648 --- Comment #3 from mybugs.m...@gmail.com 2011-07-20 14:08:21 UTC --- Thank you JeLuF!! -- 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 29983] New: Install ArticleFeedback on Portuguese Wikibooks (ptwikibooks)
https://bugzilla.wikimedia.org/show_bug.cgi?id=29983 Web browser: --- Bug #: 29983 Summary: Install ArticleFeedback on Portuguese Wikibooks (ptwikibooks) Product: Wikimedia Version: unspecified Platform: All URL: https://secure.wikimedia.org/wikibooks/pt/wiki/T%C3%B3 pico:Wikilivros:Di%C3%A1logos_comunit%C3%A1rios/Propos ta:_Ativar_a_Extens%C3%A3o:ReaderFeedback/resposta_(6) /resposta_(18)?uselang=en OS/Version: All Status: NEW Keywords: shell Severity: enhancement Priority: Unprioritized Component: Extension setup AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: mybugs.m...@gmail.com Classification: Unclassified +++ This bug was initially created as a clone of Bug #28081 +++ On Bug 27695 comment 0, Bawolff suggested the possibility of migrating from ReaderFeedback to ArticleFeedback on wikis which already have the extension installed. Some time before that, users from Portuguese Wikipedia have reached consensus about installing it on ptwiki as soon as it is available (see bug 28081) and users from other wikis have also asked about the possibility of use of AFT on their wikis (see e.g. [[mw:Thread:Talk:Article_feedback/Eswiki_article_feedback]]). A similar pool was also made on ptwikibooks and the users are favorable to switching from ReaderFeedback to ArticleFeedback extension. I don't know if the two extensions are similar enough to make it possible some kind of reuse of the data already collected by ReaderFeedback. If this is not the case, it would be good if the current data were exported to some table having at least the page names and average rating of the page. Would it be possible to do that? Per discussion on above URL, could someone setup the ArticleFeedback extension on Portuguese Wikibooks with the following configuration? $wgArticleFeedbackCategories = array(); $wgArticleFeedbackNamespaces = array( NS_MAIN, NS_HELP, NS_PROJECT ); $wgArticleFeedbackLotteryOdds = 100; $wgArticleFeedbackDashboard = true; -- 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 29983] Install ArticleFeedback on Portuguese Wikibooks (ptwikibooks)
https://bugzilla.wikimedia.org/show_bug.cgi?id=29983 --- Comment #1 from Reedy s...@reedyboy.net 2011-07-20 14:35:44 UTC --- I'm fairly sure there is no data migration path from Reader Feedback to Article Feedback -- 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 29983] Install ArticleFeedback on Portuguese Wikibooks (ptwikibooks)
https://bugzilla.wikimedia.org/show_bug.cgi?id=29983 --- Comment #2 from mybugs.m...@gmail.com 2011-07-20 14:45:01 UTC --- (In reply to comment #1) I'm fairly sure there is no data migration path from Reader Feedback to Article Feedback In this case, my previous question apply: (In reply to comment #0) If this is not the case, it would be good if the current data were exported to some table having at least the page names and average rating of the page. Would it be possible to do that? Would it be possible to provide some kind of dump file with the current ReaderFeedback data? Is this something to ask here or maybe on Database Queries service provided on Toolserver? https://jira.toolserver.org/browse/DBQ -- 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 23701] MySQL error on SMW_setup.php
https://bugzilla.wikimedia.org/show_bug.cgi?id=23701 isj i...@poczta.onet.pl changed: What|Removed |Added CC||i...@poczta.onet.pl --- Comment #6 from isj i...@poczta.onet.pl 2011-07-20 15:12:04 UTC --- Probably similar error with AUTO_INCREMENT (wikimedia 1.17) in Drafts extension (http://www.mediawiki.org/wiki/Extension_talk:Drafts). Update script raport an error: Database returned error 1: near quot;AUTOINCREMENTquot;: syntax error for proper Draft.sql content: CREATE TABLE /*_*/drafts ( -- Unique ID for drafts draft_id INTEGER AUTO_INCREMENT, ... Isn't there something wrong with wikimedia update.php which cause undescore removement from valid sql syntax? -- 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 29984] New: SocialProfile needs to be ported to ResourceLoader
https://bugzilla.wikimedia.org/show_bug.cgi?id=29984 Web browser: --- Bug #: 29984 Summary: SocialProfile needs to be ported to ResourceLoader Product: MediaWiki extensions Version: any Platform: All URL: http://www.mediawiki.org/wiki/Extension:SocialProfile/ Roadmap OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: SocialProfile AssignedTo: krinklem...@gmail.com ReportedBy: j...@countervandalism.net Classification: Unclassified Current trunk version of SocialProfile has been tested and developed against MediaWiki 1.16 and it seems that it will work only on 1.16 at the moment; it appears quite broken on current trunk version of MediaWiki (1.19alpha). I've tried porting SocialProfile to use ResourceLoader a few times now and the JS is always giving me a headache. I've rewritten SocialProfile/UserGifts/UserGifts.js to be more object-oriented, but the way its functions are (currently) used seems to be problematic when combined with the ResourceLoader; see SocialProfile/UserGifts/SpecialGiveGift.php, lines 244, 313 and 372. I'd like to retain backwards compatibility with MediaWiki 1.16 for the time being, as I need to deploy SocialProfile on some ShoutWiki sites, which still run 1.16. SystemGifts, UserActivity, UserStats and UserWelcome have only CSS files; UserSystemMessages has no CSS nor JS and the remaining modules (UserBoard, UserGifts, UserProfile, UserRelationship and UserStatus) have both CSS and JS files. Assigning to Krinkle as per Reedy's suggestion on #mediawiki: 08:02 ashley to whom might I assign a ResourceLoader-related bug? specifically, my SocialProfile extension appears to be rather...broken in current trunk (and probably for 1.17+ in general) and it needs to be ported to use RL (retaining backwards compat w/ 1.16) but jQuery and RL are driving me crazy :-/ 08:02 Reedy ashley, Roan, Trevor or maybe Krinkle -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 29693] Resource Loader loads CSS multiple times
https://bugzilla.wikimedia.org/show_bug.cgi?id=29693 --- Comment #8 from Subfader subfa...@gmail.com 2011-07-20 16:15:45 UTC --- Thanks, that works. -- 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 29830] Enable Extension:WikiLove on Hindi Wikipedia
https://bugzilla.wikimedia.org/show_bug.cgi?id=29830 --- Comment #19 from Vaibhav Jain vibhij...@yahoo.in 2011-07-20 16:33:04 UTC --- Please tell what are the content for translation? -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 29830] Enable Extension:WikiLove on Hindi Wikipedia
https://bugzilla.wikimedia.org/show_bug.cgi?id=29830 --- Comment #20 from Reedy s...@reedyboy.net 2011-07-20 16:34:05 UTC --- (In reply to comment #19) Please tell what are the content for translation? (In reply to comment #12) It doesn't look like the config has been localized yet: http://hi.wikipedia.org/wiki/MediaWiki:WikiLove.js -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 29830] Enable Extension:WikiLove on Hindi Wikipedia
https://bugzilla.wikimedia.org/show_bug.cgi?id=29830 --- Comment #21 from Casey Brown b...@caseybrown.org 2011-07-20 16:35:37 UTC --- And it's not translation, it's localization. You change the config to fit the templates and barnstar/gift/love system on hiwiki. You don't just translate exactly what enwiki has. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 29830] Enable Extension:WikiLove on Hindi Wikipedia
https://bugzilla.wikimedia.org/show_bug.cgi?id=29830 --- Comment #22 from Ryan Kaldari rkald...@wikimedia.org 2011-07-20 16:57:16 UTC --- The documentation for configuring WikiLove is here: http://www.mediawiki.org/wiki/Extension:WikiLove#Custom_configuration The local configuration page is here: http://hi.wikipedia.org/wiki/MediaWiki:WikiLove.js I would consider the minimum requirement to be replacing all the English messages with Hindi. What would be nice, though, is if the items are replaced with whatever items are commonly used as gifts on the Hindi Wiki, as Casey said above. The only reason the English Wikipedia has cheeseburgers and kittens in their WikiLove is because those are the items that people were already using as virtual gifts on the project. The items should be tailored to the culture of the wiki. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 29830] Enable Extension:WikiLove on Hindi Wikipedia
https://bugzilla.wikimedia.org/show_bug.cgi?id=29830 --- Comment #23 from mayurkumar mayur...@gmail.com 2011-07-20 17:01:06 UTC --- (In reply to comment #22) The documentation for configuring WikiLove is here: http://www.mediawiki.org/wiki/Extension:WikiLove#Custom_configuration The local configuration page is here: http://hi.wikipedia.org/wiki/MediaWiki:WikiLove.js I would consider the minimum requirement to be replacing all the English messages with Hindi. What would be nice, though, is if the items are replaced with whatever items are commonly used as gifts on the Hindi Wiki, as Casey said above. The only reason the English Wikipedia has cheeseburgers and kittens in their WikiLove is because those are the items that people were already using as virtual gifts on the project. The items should be tailored to the culture of the wiki. We will surely do that but let it be done by our users suggestion about this extension we will do the same as per their suggestion.I assure you to done that localization ASAP.Regards -- 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 29981] Clicking link to secure site takes me to insecure site
https://bugzilla.wikimedia.org/show_bug.cgi?id=29981 --- Comment #1 from Brion Vibber br...@wikimedia.org 2011-07-20 17:22:37 UTC --- I assume the link you're clicking is the https://office.wikimedia.org/ link... I can confirm the behavior you're seeing in Firefox 5/Linux. :( Hitting the / generic root page will end up sending a redirect to the canonical location of the main page; sounds like either MediaWiki's incorrectly serving out the HTTP redirect, or it's getting incorrectly cached. Looks like I can repro with another redirection, using a non-canonical encoding of the title: https://office.wikimedia.org/wiki/Main%20Page also gets redirected to: http://office.wikimedia.org/wiki/Main_Page HTTP response headers as seen in Firebug on a redir: Servernginx/0.7.65 DateWed, 20 Jul 2011 17:20:12 GMT Content-Typetext/html; charset=utf-8 Connectionkeep-alive Cache-Controls-maxage=1200, must-revalidate, max-age=0 VaryAccept-Encoding,Cookie X-Vary-Options Accept-Encoding;list-contains=gzip,Cookie;string-contains=officewikiToken;string-contains=officewikiLoggedOut;string-contains=officewiki_session Last-ModifiedWed, 20 Jul 2011 17:18:54 GMT Locationhttp://office.wikimedia.org/wiki/Main_Page Content-Encodinggzip Content-Length20 Age78 X-CacheHIT from sq62.wikimedia.org, MISS from sq40.wikimedia.org X-Cache-LookupHIT from sq62.wikimedia.org:3128, MISS from sq40.wikimedia.org:80 Via1.1 sq62.wikimedia.org:3128 (squid/2.7.STABLE7), 1.0 sq40.wikimedia.org:80 (squid/2.7.STABLE7) it looks like the redirect is built fresh, not just cached at least in this case, but it's getting built out with the HTTP form. Either MediaWiki is formatting the Location: URL as HTTP, or the proxies in front of it are expanding it from protocol-relative and doing so as http. -- 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 29981] Clicking link to secure site takes me to insecure site
https://bugzilla.wikimedia.org/show_bug.cgi?id=29981 --- Comment #2 from Brion Vibber br...@wikimedia.org 2011-07-20 17:26:43 UTC --- The redirect target appears to be built with WebRequest::getFullRequestURL() which uses $wgServer, which in this case I think ought to be the protocol-relative link. This then doesn't seem to get expanded further, so it might be nginx (the https proxies) that are expanding it to http:// or else the caches or? We do though output a 301 here which is meant to be cacheable; so if that happens below the cache layer we could also be caching things incorrectly. -- 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 27946] Secure Server (Tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=27946 Brion Vibber br...@wikimedia.org changed: What|Removed |Added Depends on||29977, 29981 -- 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 29977] Description url in imageinfo ouputs protocol relative urls
https://bugzilla.wikimedia.org/show_bug.cgi?id=29977 Brion Vibber br...@wikimedia.org changed: What|Removed |Added Blocks||27946 -- 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 29981] Clicking link to secure site takes me to insecure site
https://bugzilla.wikimedia.org/show_bug.cgi?id=29981 Brion Vibber br...@wikimedia.org changed: What|Removed |Added Blocks||27946 -- 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 29976] protocol relative uri for meta edituri
https://bugzilla.wikimedia.org/show_bug.cgi?id=29976 --- Comment #2 from Brion Vibber br...@wikimedia.org 2011-07-20 17:33:57 UTC --- I'd say if this needs to be changed, just use a local relative link with the path only. It'll be just as accurate, smaller in output, and slightly more likely to be supported by clients doing discovery. -- 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 29918] $wgRightsText shouldn't be required if $wgRightsUrl is specified
https://bugzilla.wikimedia.org/show_bug.cgi?id=29918 Brion Vibber br...@wikimedia.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Brion Vibber br...@wikimedia.org 2011-07-20 17:53:24 UTC --- The link URL, textual name, and icon URL are set at install time by the installer, either from its own predefined list or from the data returned from the Creative Commons license picker web thingy. Per code comments, it looks pretty clear by definition that the two must be set together: /** * If either $wgRightsUrl or $wgRightsPage is specified then this variable gives the text for the link. * If using $wgRightsUrl then this value must be specified. If using $wgRightsPage then the name of the * page will also be used as the link if this variable is not set. */ $wgRightsText = null; -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 29972] Malformed header errors with the new installer
https://bugzilla.wikimedia.org/show_bug.cgi?id=29972 --- Comment #1 from Brion Vibber br...@wikimedia.org 2011-07-20 17:56:54 UTC --- This output line comes from convertLinks, which is a Maintenance subclass... ...it does the output with its $this-output() method, which on Maintenance looks like it tries to output *directly* to stdout, instead of a generic 'print' or 'echo'. It's possible that this is interfering with output header buffering, especially if this is a PHP-as-CGI or FastCGI setup. -- 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 29976] protocol relative uri for meta edituri
https://bugzilla.wikimedia.org/show_bug.cgi?id=29976 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added AssignedTo|wikibugs-l@lists.wikimedia. |roan.katt...@gmail.com |org | -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 29977] Description url in imageinfo ouputs protocol relative urls
https://bugzilla.wikimedia.org/show_bug.cgi?id=29977 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added AssignedTo|wikibugs-l@lists.wikimedia. |roan.katt...@gmail.com |org | -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 29981] Location: redirects on https sites always point to http sites
https://bugzilla.wikimedia.org/show_bug.cgi?id=29981 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added CC||roan.katt...@gmail.com Summary|Clicking link to secure |Location: redirects on |site takes me to insecure |https sites always point to |site|http sites -- 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 29981] Location: redirects on https sites always point to http sites
https://bugzilla.wikimedia.org/show_bug.cgi?id=29981 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added AssignedTo|wikibugs-l@lists.wikimedia. |roan.katt...@gmail.com |org | --- Comment #3 from Roan Kattouw roan.katt...@gmail.com 2011-07-20 18:01:30 UTC --- This is an issue with other things as well, such as the redirect after submitting the login form: you log in over https, and after logging you in MW will happily send you to http. -- 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 29210] Make ВП: a namespace alias for the project namespace at ukwiki
https://bugzilla.wikimedia.org/show_bug.cgi?id=29210 --- Comment #13 from microce...@gmail.com 2011-07-20 18:44:27 UTC --- There's only one letter which needs changing in the code. No problems occur with using ВЦ: as the alias, but it's incorrect and doesn't match existing shortcuts. Please, do this small change so that we could ask additional questions in case something goes wrong. -- 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 29985] New: Logo request
https://bugzilla.wikimedia.org/show_bug.cgi?id=29985 Web browser: --- Bug #: 29985 Summary: Logo request Product: Wikimedia Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: Site logos AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: serv...@gmail.com Classification: Unclassified Can someone create a new logo for nds-nl.wikipedia with the text WikipediE - De vrieje ensyklopedie. Thanks in advance. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 29970] Better handling of linked parameters in parser functions
https://bugzilla.wikimedia.org/show_bug.cgi?id=29970 Gustavo gustron...@gmail.com changed: What|Removed |Added CC||gustron...@gmail.com --- Comment #2 from Gustavo gustron...@gmail.com 2011-07-20 19:12:32 UTC --- (In reply to comment #1) Are you sure it will MAINLY and JUST do that? I don't think so. What it will mainly do is to increase the likelihood that something that currently does not work will properly be parsed. Those few things that aren't whole and unique links and will happen to get thrown in there will *still* not work, as they currently don't. But those many that *are* what is expected will do. Of course, this proposal is intended to be done only for namespaces- and pagenames-related functions. -- 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 28574] Proofread doesn't add buttons to wikiEditor toolbar, only to legacy one.
https://bugzilla.wikimedia.org/show_bug.cgi?id=28574 --- Comment #11 from mybugs.m...@gmail.com 2011-07-20 19:24:48 UTC --- Brion, I'm not sure this is was caused by the recent changes, but a user reported the following on English Wikisource: I may be wrong, but I assume that it is this fix that may have introduced a minor glitch into Proofread Page: until a few days ago, when in zoom mode, the mouse cursor changed to crosshairs, while scroll mode was the normal arrow. Now it is the arrow in both modes, which is an inconvenience. https://secure.wikimedia.org/wikisource/en/w/index.php?title=Wikisource%3AScriptoriumaction=historysubmitdiff=3176709oldid=3176578 And when I go to the page http://de.wikisource.org/w/index.php?title=Seite:Arthur_Schnitzler_%E2%80%93_Flucht_in_die_Finsternis_%E2%80%93_141.jpgaction=editdebug=1 using Chromium 12.0.742.112 (90304) Ubuntu 11.04, and click on the image, I get the following error: Uncaught TypeError: Cannot set property 'cssText' of undefined pr_dropproofread.js:435 On Firefox 5.0 the error is pr_rect.style is undefined http://bits.wikimedia.org/w/extensions-1.17/ProofreadPage/proofread.js Line 435 pr_rect.style.cssText = display:none; -- 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 29986] New: $wgSecureLogin fails to handle page links, non-SSL content
https://bugzilla.wikimedia.org/show_bug.cgi?id=29986 Web browser: --- Bug #: 29986 Summary: $wgSecureLogin fails to handle page links, non-SSL content Product: MediaWiki Version: 1.17 Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: User login AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: mediaw...@blazemonger.com Classification: Unclassified Created attachment 8806 -- https://bugzilla.wikimedia.org/attachment.cgi?id=8806 SecureLoginPage.php The SSL login feature enabled by $wgSecureLogin produces pages that can be confusing to users. Here are several use cases that happen when $wgSecureLogin=true. 1. User clicks Log in. On the login page (which is https), the user does not log in, but clicks another link on the page such as Recent changes. This link is also https. Suddenly the user is viewing the wiki via SSL, when this might never have been the user's intention. 2. User clicks Log in. The logo image, which was set by a sysadmin via $wgLogo to be http://some.other.site/myfile.jpg;, gets served over http. The browser (IE) pops up a warning, Do you want to view only the webpage content that was delivered securely? The user gets confused or scared by the popup. Several years ago I published a SecureUserLogin extension in my O'Reilly MediaWiki book. It avoids problem 1 by automatically switching from https to http when serving pages other than the login page. (Unless the user wants a totally SSL session.) I believe MediaWiki should do similarly. I will attach a copy of the extension in case it's useful to you. -- 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 29986] $wgSecureLogin fails to handle page links, non-SSL content
https://bugzilla.wikimedia.org/show_bug.cgi?id=29986 --- Comment #1 from Dan Barrett mediaw...@blazemonger.com 2011-07-20 19:47:30 UTC --- Created attachment 8807 -- https://bugzilla.wikimedia.org/attachment.cgi?id=8807 SecureLoginPage_body.php -- 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 29929] Failed db upgrade from 1.14
https://bugzilla.wikimedia.org/show_bug.cgi?id=29929 --- Comment #8 from P.Muller pierre1...@gmail.com 2011-07-20 19:54:54 UTC --- I simply applied maintenance/archives/patch-log_user_text.sql before the upgrade, then php update.php worked seamlessly. -- 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 26813] patch ContactPageFundraiser (foundationwiki contactpage extension) to add variable for age from story submission
https://bugzilla.wikimedia.org/show_bug.cgi?id=26813 James Alexander jalexan...@wikimedia.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED AssignedTo|wikibugs-l@lists.wikimedia. |jalexan...@wikimedia.org |org | --- Comment #3 from James Alexander jalexan...@wikimedia.org 2011-07-20 20:23:01 UTC --- This patch ended up being thrown out but a similar adjustment was done in r92041 which was pushed to live today. It's still preferable to have the two extensions combined but given that it works for what we need right now it isn't on the priority list for the moment at least for the fundraiser. -- 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 29976] protocol relative uri for meta edituri
https://bugzilla.wikimedia.org/show_bug.cgi?id=29976 --- Comment #3 from Derk-Jan Hartman hart...@videolan.org 2011-07-20 20:25:26 UTC --- Created attachment 8808 -- https://bugzilla.wikimedia.org/attachment.cgi?id=8808 dze path is simple Relates to Bug 25648. Fear is that some of the clients actually using this URL might not support any relative url form. We probably need a set of testcases so that we can file upstream bugs. -- 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 29986] $wgSecureLogin fails to handle page links, non-SSL content
https://bugzilla.wikimedia.org/show_bug.cgi?id=29986 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added CC||roan.katt...@gmail.com --- Comment #2 from Roan Kattouw roan.katt...@gmail.com 2011-07-20 20:25:57 UTC --- We're already working on making URLs in MediaWiki protocol-relative as much as possible. Basically, if you set $wgServer = '//wiki.example.com'; in trunk as of a few days ago, that'll mostly work as you expect. -- 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 29986] $wgSecureLogin fails to handle page links, non-SSL content
https://bugzilla.wikimedia.org/show_bug.cgi?id=29986 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added Attachment #8806|text/x-wiki |text/plain mime type|| --- Comment #3 from Roan Kattouw roan.katt...@gmail.com 2011-07-20 20:28:57 UTC --- Comment on attachment 8806 -- https://bugzilla.wikimedia.org/attachment.cgi?id=8806 SecureLoginPage.php Change MIME types of PHP files to plain text so Bugzilla will hopefully display them to me without making me download them. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 29986] $wgSecureLogin fails to handle page links, non-SSL content
https://bugzilla.wikimedia.org/show_bug.cgi?id=29986 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added Attachment #8807|text/x-wiki |text/plain mime type|| -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 29968] Enable XFN rel=me for links on User Profile pages and rel=author links on topic articles
https://bugzilla.wikimedia.org/show_bug.cgi?id=29968 --- Comment #5 from Derk-Jan Hartman hart...@videolan.org 2011-07-20 20:32:52 UTC --- Another place where rel=author could be used might be in user's signatures on talk pages I guess. -- 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 14766] GroupPermissionManager send error messages
https://bugzilla.wikimedia.org/show_bug.cgi?id=14766 Mark A. Hershberger m...@everybody.org changed: What|Removed |Added CC||m...@everybody.org Component|GroupPermissionsManager |[other] AssignedTo|skizz...@gmail.com |wikibugs-l@lists.wikimedia. ||org -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 16318] PHP warning on SortPermissions.php
https://bugzilla.wikimedia.org/show_bug.cgi?id=16318 Mark A. Hershberger m...@everybody.org changed: What|Removed |Added CC||m...@everybody.org Component|GroupPermissionsManager |[other] AssignedTo|skizz...@gmail.com |wikibugs-l@lists.wikimedia. ||org -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 21017] Red links to new discussion pages cause endless loop when clicked
https://bugzilla.wikimedia.org/show_bug.cgi?id=21017 Mark A. Hershberger m...@everybody.org changed: What|Removed |Added CC||m...@everybody.org Component|GroupPermissionsManager |[other] AssignedTo|skizz...@gmail.com |wikibugs-l@lists.wikimedia. ||org -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 29986] $wgSecureLogin fails to handle page links, non-SSL content
https://bugzilla.wikimedia.org/show_bug.cgi?id=29986 --- Comment #4 from Brion Vibber br...@wikimedia.org 2011-07-20 20:35:12 UTC --- Using protocol-relative links doesn't have any effect on case 1) since those links are always on the local protocol/host anyway. Proper 'fix' for that is of course to always use SSL for all logged-in sessions at all times, which is much safer. -- 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 14766] GroupPermissionManager send error messages
https://bugzilla.wikimedia.org/show_bug.cgi?id=14766 Mark A. Hershberger m...@everybody.org changed: What|Removed |Added Resolution|FIXED |INVALID -- 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 21017] Red links to new discussion pages cause endless loop when clicked
https://bugzilla.wikimedia.org/show_bug.cgi?id=21017 Mark A. Hershberger m...@everybody.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID -- 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 16318] PHP warning on SortPermissions.php
https://bugzilla.wikimedia.org/show_bug.cgi?id=16318 Mark A. Hershberger m...@everybody.org changed: What|Removed |Added Resolution|FIXED |INVALID -- 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 29986] $wgSecureLogin fails to handle page links, non-SSL content
https://bugzilla.wikimedia.org/show_bug.cgi?id=29986 --- Comment #5 from Dan Barrett mediaw...@blazemonger.com 2011-07-20 20:41:57 UTC --- Brion: I see your point about security. Until such time that Wikipedia goes 100% SSL, it would be great if the secure login feature just followed the contract with its user: delivering articles over http unless the user has logged in and checked the everything SSL checkbox. Seem reasonable? -- 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 14766] GroupPermissionManager send error messages
https://bugzilla.wikimedia.org/show_bug.cgi?id=14766 --- Comment #2 from Mark A. Hershberger m...@everybody.org 2011-07-20 20:48:12 UTC --- Marked invalid since the entire extension was removed from Bz at the request of the Ryan who said the extension was no longer under development. -- 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 29987] New: Weird behavior of [[Special:Search]]
https://bugzilla.wikimedia.org/show_bug.cgi?id=29987 Web browser: --- Bug #: 29987 Summary: Weird behavior of [[Special:Search]] Product: MediaWiki Version: 1.19-svn Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: Search AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: mybugs.m...@gmail.com Classification: Unclassified 1) Go to [[Main Page]] 2) Type in the search box something like: Just a test 3) Press ENTER, and you will be taken to the page http://en.wikipedia.org/w/index.php?title=Special%3ASearchsearch=Just+a+test 4) Click in the link Help and Project pages which takes you to http://en.wikipedia.org/w/index.php?title=Special:Searchsearch=Just%20a%20testfulltext=Searchns4=1ns12=1redirs=0 which shows Results 1–20 of 21,183 for Just a test 5) Click in the link to show 500 items (in the bottom of the page) View (previous 20 | next 20) (20 | 50 | 100 | 250 | [[500]]) This will take you to http://en.wikipedia.org/w/index.php?title=Special:Searchns4=1ns12=1redirs=1search=Just+a+testlimit=500offset=0 which shows There were no results matching the query. This is very weird because when the user clicks on 500 it expects to see [[more results]], not [[less]] (and certainly not [[no results at all]]) Why is this happening? -- 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 16318] PHP warning on SortPermissions.php
https://bugzilla.wikimedia.org/show_bug.cgi?id=16318 --- Comment #5 from Mark A. Hershberger m...@everybody.org 2011-07-20 20:48:29 UTC --- Marked invalid since the entire extension was removed from Bz at the request of the Ryan who said the extension was no longer under development. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 29968] Enable XFN rel=me for links on User Profile pages and rel=author links on topic articles
https://bugzilla.wikimedia.org/show_bug.cgi?id=29968 --- Comment #6 from Derk-Jan Hartman hart...@videolan.org 2011-07-20 20:48:30 UTC --- Created attachment 8809 -- https://bugzilla.wikimedia.org/attachment.cgi?id=8809 add rel=author to userlinks Adds the author link to userlinks. (all of them) We probably want to special case this a bit (keep it to just revUserTools() perhaps ? Callpath for formatting userlinks in historypages. includes/HistoryPage.php:HistoryPage: history() includes/HistoryPage.php:HistoryPager formatRow() includes/HistoryPage.php:HistoryPager historyLine() includes/Linker.php: revUserTools() includes/Linker.php: userLink() -- 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 21017] Red links to new discussion pages cause endless loop when clicked
https://bugzilla.wikimedia.org/show_bug.cgi?id=21017 --- Comment #1 from Mark A. Hershberger m...@everybody.org 2011-07-20 20:48:41 UTC --- Marked invalid since the entire extension was removed from Bz at the request of the Ryan who said the extension was no longer under development. -- 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 29987] Weird behavior of [[Special:Search]]
https://bugzilla.wikimedia.org/show_bug.cgi?id=29987 Robert Stojnic rain...@eunet.rs changed: What|Removed |Added CC||rain...@eunet.rs --- Comment #1 from Robert Stojnic rain...@eunet.rs 2011-07-20 20:51:04 UTC --- Backend timeout. During high load times, it can take more time than the current timeout (6s? 10s?) to actually fetch the results, so you get zero results. Reloading the page a couple of times you eventually give you the results. -- 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 29988] New: Category, template, and form semantic metadata needed automatically for each page that uses them
https://bugzilla.wikimedia.org/show_bug.cgi?id=29988 Web browser: --- Bug #: 29988 Summary: Category, template, and form semantic metadata needed automatically for each page that uses them Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Unprioritized Component: Semantic MediaWiki AssignedTo: mar...@semantic-mediawiki.org ReportedBy: fastgoldf...@gmail.com CC: jeroen_ded...@yahoo.com Classification: Unclassified We already get property data in the factbox, which is very handy for developing, maintaining, and using a semantic mediawiki. All that remains to be added is information about categories, templates, and forms that are used for the page. Likewise, categories, templates, and forms could also have information about which of those three things go into defining them (like if a template is created by a form, or if a category is contained in a template). I have been able to manually add these features to this page (user Demo, pass dedauw): http://www.coincompendium.com/wiki/index.php/File:1989GWWcto.jpg Wiki developers, maintainers, and users can easily access the categories, templates, and forms that go into creating that page, all in place. In addition, I'm able to query the semantic data to display on the template page which pages are using the template: http://www.coincompendium.com/wiki/index.php/Template:Image The nature of these things makes it straightforward to add them manually once, and then use them unlimited numbers of times. However, if the properties Category, Template, and Form were part of the metadata of each page, they could be displayed in the factbox that already handles other properties. Also, my factboxes do not show special metadata properties like the Modification date property that currently exists - this should be at least optional, if not the default). See also: https://bugzilla.wikimedia.org/show_bug.cgi?id=13151 -- 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 13151] Transfer some Features from DPL to ask
https://bugzilla.wikimedia.org/show_bug.cgi?id=13151 --- Comment #7 from fastgoldf...@gmail.com 2011-07-20 20:53:21 UTC --- I created another bug report as an enhancement of this one: https://bugzilla.wikimedia.org/show_bug.cgi?id=29988 -- 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 29987] Weird behavior of [[Special:Search]]
https://bugzilla.wikimedia.org/show_bug.cgi?id=29987 --- Comment #2 from mybugs.m...@gmail.com 2011-07-20 20:57:17 UTC --- (In reply to comment #1) Reloading the page a couple of times you eventually give you the results. Doesn't seems to solve the problem here. On the other hand, if I click on Search button again, some results are displayed, but the option limit=500 is then discarded (and if I click on 500 again I get no results). -- 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 16863] Reverse Collapse button for rtl wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=16863 James Alexander jalexan...@wikimedia.org changed: What|Removed |Added CC||jalexan...@wikimedia.org Resolution|LATER |FIXED AssignedTo|tf...@wikimedia.org |jalexan...@wikimedia.org --- Comment #3 from James Alexander jalexan...@wikimedia.org 2011-07-20 21:25:09 UTC --- I'm grabbing this and marking fixed. Old ticket but I'm pretty certain we did this for almost all banners last year. If it wasn't we can and it will be done this year. -- 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 29989] New: MW should provide better messages if the search terms contains part of the search syntax
https://bugzilla.wikimedia.org/show_bug.cgi?id=29989 Web browser: --- Bug #: 29989 Summary: MW should provide better messages if the search terms contains part of the search syntax Product: MediaWiki Version: 1.19-svn Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: Search AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: mybugs.m...@gmail.com Classification: Unclassified Consider the following examples 1) two or three words http://en.wikipedia.org/w/index.php?title=Special:Searchsearch=%22two+or+three+words%22fulltext=Search The page [[two or three words]] doesn't exists and MW shows the message There were no results matching the query. Create the page two or three words on this wiki! Since the quotes have a special meaning when used among the search terms, i.e. they are part of the search syntax, the messages should be more contextualized. For example, if we search for some words on Google Search Engine, we will get: http://www.google.com/search?q=%22some+words+on+Google+Search+Engine%22 No results found for some words on Google Search Engine. Results for some words on Google Search Engine (without quotes): ... 2) intitle:Another example http://en.wikipedia.org/w/index.php?title=Special:Searchsearch=intitle%3Aanother+examplefulltext=Search There were no results matching the query. Create the page Intitle:another example on this wiki! the string intitle also has a special meaning, so when the user uses it, and get no results, MW could provide some indication that by dropping that term there could be some result. The same idea applies to other strings having special meanings, such as prefix and symbols like - which is used to exclude some of the possible results. -- 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 29989] MW should provide better messages if the search terms contains part of the search syntax
https://bugzilla.wikimedia.org/show_bug.cgi?id=29989 --- Comment #1 from mybugs.m...@gmail.com 2011-07-20 21:32:19 UTC --- (In reply to comment #0) The same idea applies to other strings having special meanings, such as prefix and symbols like - which is used to exclude some of the possible results. ...and also to ondiscussionpage, which is currently used by [[mw:Extension:LiquidThreads]] http://www.mediawiki.org/w/index.php?title=Special:Searchsearch=EXAMPLE+ondiscussionpage%3ATalk%3AArticle+feedbackfulltext=1ns90=1 and may lead to the creation of pages like http://pt.wikibooks.org/w/index.php?title=Porque_somos_jogados_para_frente_do_%C3%B4nibus_quando_ele_freia_bruscamente_ondiscussionpage:Wikilivros:Pergunte_ao_bibliotec%C3%A1rioaction=editredlink=1 which will need to be deleted. -- 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 29989] Provide better messages if the search phrase contains part of the search syntax
https://bugzilla.wikimedia.org/show_bug.cgi?id=29989 Krinkle krinklem...@gmail.com changed: What|Removed |Added CC||krinklem...@gmail.com Summary|MW should provide better|Provide better messages if |messages if the search |the search phrase contains |terms contains part of the |part of the search syntax |search syntax | -- 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 29985] Logo request
https://bugzilla.wikimedia.org/show_bug.cgi?id=29985 --- Comment #1 from Reedy s...@reedyboy.net 2011-07-20 22:01:54 UTC --- This isn't really the place to ask this... I'd guess asking on commons/meta would yield more results -- 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 29982] Enable [[mw:Extension:FlaggedRevs]] on ptwikibooks
https://bugzilla.wikimedia.org/show_bug.cgi?id=29982 Reedy s...@reedyboy.net changed: What|Removed |Added Status|NEW |RESOLVED Depends on||29744 Resolution||LATER Severity|normal |enhancement --- Comment #1 from Reedy s...@reedyboy.net 2011-07-20 22:03:26 UTC --- At the moment, the Wikimedia Foundation is not activating FlaggedRevs on any new wikis, pending further discussion on the extensions future. Marking as RESOLVED LATER, tracked against bug 29744 -- 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 29744] Flagged rev installation tracking bug
https://bugzilla.wikimedia.org/show_bug.cgi?id=29744 Reedy s...@reedyboy.net changed: What|Removed |Added Blocks||29982 -- 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 29990] New: Signature script and potential double-posting
https://bugzilla.wikimedia.org/show_bug.cgi?id=29990 Web browser: --- Bug #: 29990 Summary: Signature script and potential double-posting Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: Page editing AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: lord.god.jin...@gmail.com Classification: Unclassified The signature script () appears to cause the page trouble and the software tries to double-post on my system often. Fortunatly the script itself changes on the talk pages so it defaults to a edit conflict error. However, that means I don't default back to the main talk page as I should, but to the edit talk page and have to check each time to make certain it was just that and not a true edit conflict with another user. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 29990] Signature script and potential double-posting
https://bugzilla.wikimedia.org/show_bug.cgi?id=29990 --- Comment #1 from Jinnai lord.god.jin...@gmail.com 2011-07-20 22:06:37 UTC --- Forgot to add: Running Firefox 5, Windows 7 x64 -- 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 29982] Enable [[mw:Extension:FlaggedRevs]] on ptwikibooks
https://bugzilla.wikimedia.org/show_bug.cgi?id=29982 --- Comment #2 from mybugs.m...@gmail.com 2011-07-20 22:08:54 UTC --- Is there any detailed reason for this decision available anywhere? -- 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 29990] Signature script and potential double-posting
https://bugzilla.wikimedia.org/show_bug.cgi?id=29990 Dan Collins en.wp.s...@gmail.com changed: What|Removed |Added CC||en.wp.s...@gmail.com --- Comment #2 from Dan Collins en.wp.s...@gmail.com 2011-07-20 22:09:52 UTC --- Sounds like the sort of thing that would happen if the page load is slow and you click the save page button more than once. Does this occur if you're careful to click save page only once? Does it occur if you make a test edit including a subst:ed template, but no signature? Does it occur consistently? What wiki does this occur on, what browser are you using, and do you have any custom javascript? Note that if this occurs when the form is actually submitted twice (for any reason), this is a dupe of bug 17368. If this occurs even if the form is only submitted once, then something strange is happening. -- 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 29985] Logo request
https://bugzilla.wikimedia.org/show_bug.cgi?id=29985 Casey Brown b...@caseybrown.org changed: What|Removed |Added Status|NEW |RESOLVED CC||b...@caseybrown.org Resolution||INVALID --- Comment #2 from Casey Brown b...@caseybrown.org 2011-07-20 22:24:33 UTC --- See [[m:Requests for logos]]. -- 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 29840] Add action=diff for diff pages
https://bugzilla.wikimedia.org/show_bug.cgi?id=29840 Brion Vibber br...@wikimedia.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #2 from Brion Vibber br...@wikimedia.org 2011-07-20 22:29:42 UTC --- Closing this one out as a WONTFIX for now; could reconsider for future if we actually do a major overhaul of the diff view feature. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 29840] Add action=diff for diff pages
https://bugzilla.wikimedia.org/show_bug.cgi?id=29840 Krinkle krinklem...@gmail.com changed: What|Removed |Added CC||krinklem...@gmail.com --- Comment #3 from Krinkle krinklem...@gmail.com 2011-07-20 22:32:13 UTC --- A bit related is bug 27930 -- 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
