headers
bugzilla-daemon | 1 Jan 2009 01:05
Picon

[Bug 16806] Inline links to files are no longer being registered in the link table or image table , or anywhere apparently

https://bugzilla.wikimedia.org/show_bug.cgi?id=16806

Brion Vibber <brion <at> wikimedia.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #5 from Brion Vibber <brion <at> wikimedia.org>  2009-01-01 00:05:48 UTC ---
Patched this up in r45266.

Fixes other cases broken by Parser's assumptions failing to hold after change
in Title::isAlwaysKnown()'s behavior:
* Links to invalid Special: pages were being recorded, but shouldn't
* Links to valid MediaWiki: pages were no longer recorded

Instead of the NS_FILE special-case in r45174, I'm just tossing *all*
isAlwaysKnown links over to ParserOutput::addLink(), and letting the latter
worry about what types of titles it won't record.
Just for good measure, in case any NS_MEDIA titles make it into
ParserOutput::addLink() they'll be normalized to NS_FILE.

--

-- 
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.
Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 Jan 2009 01:23
Picon

[Bug 16162] Negative namespace titles handled inconsistently

https://bugzilla.wikimedia.org/show_bug.cgi?id=16162

Brion Vibber <brion <at> wikimedia.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |brion <at> wikimedia.org
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #2 from Brion Vibber <brion <at> wikimedia.org>  2009-01-01 00:23:13 UTC ---
This was a side effect of enforcement of looks being distributed in various
different places.

Changes to Title::isAlwaysKnown() caused the behavior to become inconsistent
for inline links (with existing special pages not getting recorded, while
nonexistent ones ended up going through the main code path and now getting
recorded), while the image link target one simply went through a new, very
different code path and got recorded.

I've now moved the special checks explicitly into ParserOutput::addLink() in
r45266 for bug 16806, so behavior should be nice and consistent.

For now the special links are not being recorded. It could be useful to start
recording them, but we'd want to do a few things:
* Normalize the link names to canonical form
* Consider a way to deal with parameters
* Add UI for all the various "show me stuff from the link tables" to
consistently allow doing something with that data
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 Jan 2009 01:23
Picon

[Bug 16806] Inline links to files are no longer being registered in the link table or image table , or anywhere apparently

https://bugzilla.wikimedia.org/show_bug.cgi?id=16806

--- Comment #6 from Brion Vibber <brion <at> wikimedia.org>  2009-01-01 00:23:30 UTC ---
Cf bug 16162.

--

-- 
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.
Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 Jan 2009 01:55
Picon

[Bug 16853] Regression: CodeReview revision form no longer links to new comment after posting

https://bugzilla.wikimedia.org/show_bug.cgi?id=16853

Aaron Schulz <JSchulz_4587 <at> msn.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Aaron Schulz <JSchulz_4587 <at> msn.com>  2009-01-01 00:55:25 UTC ---
Fixed in r45268

--

-- 
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.
Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 Jan 2009 01:55
Picon

[Bug 5552] add a fulltext-only search mode to inputbox

https://bugzilla.wikimedia.org/show_bug.cgi?id=5552

Robert Stojnic <rainman <at> EUnet.yu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #3 from Robert Stojnic <rainman <at> EUnet.yu>  2009-01-01 00:55:53 UTC ---
Another attempt with type=fulltext in r45269.

--

-- 
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.
Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 Jan 2009 06:47
Picon

[Bug 2581] View image in several resolutions

https://bugzilla.wikimedia.org/show_bug.cgi?id=2581

Sage Ross <ragesoss <at> gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ragesoss <at> gmail.com

--- Comment #7 from Sage Ross <ragesoss <at> gmail.com>  2009-01-01 05:47:13 UTC ---
I think such a feature is becoming more of a need, especially as file sizes and
resolutions grow very large.  We will soon have a Featured Picture in English
Wikipedia, e.g., that is 37 MB (
http://en.wikipedia.org/wiki/File:Great_Wave_off_Kanagawa2.jpg ).  So unless
someone wants to download all that (or knows how to work the thumbnail syntax)
they are limited to the default display size and cannot view a moderately-sized
larger version.  A Flickr-like feature that makes it easy to access a range of
image sizes, and/or an option to download a reasonably compressed version of a
file, would be helpful for users with slow connections.

I don't think feature cruft should be a big concern right now for image pages,
which don't have very many useful bells or whistles for the less wiki-savvy
users.

--

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.
Permalink | Reply | 1 comment |
headers
bugzilla-daemon | 1 Jan 2009 10:40
Picon

[Bug 13451] Technical updates to bs.wiki

https://bugzilla.wikimedia.org/show_bug.cgi?id=13451

--- Comment #8 from Elmir <demicx <at> medistan.de>  2009-01-01 09:40:43 UTC ---
Please get this done as soon as possible! Thanks.

--

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.
Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 Jan 2009 10:50
Picon

[Bug 16855] New: Suggestion: Basic blog included in next mediawiki

https://bugzilla.wikimedia.org/show_bug.cgi?id=16855

           Summary: Suggestion: Basic blog included in next mediawiki
           Product: MediaWiki
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: Normal
         Component: Templates
        AssignedTo: wikibugs-l <at> lists.wikimedia.org
        ReportedBy: tim987 <at> email.com

Currently mediawiki doesn't have a basic blog so the wiki site owner cannot
talk to the users and get their comments. For example if the wiki site owner
wanted to get opinions of users on a new site design they could blog about it.

Yes i know mediawiki has a sitenotice but it will take up too much header space
if it was used as a blog.

Yes i know there are extensions but they are for users to have a blog which can
only be viewed my going to their page.

The blog i want mediawiki to have will only be for the admin and there will be
a button called "blog" in the sidebar. The admin should be able to post a photo
and text and users can comment. It will have a captcha for comments. It will
use the wiki's current mysql database and display 20 previous blog posts per
page.
(Continue reading)

Permalink | Reply | 3 comments |
headers
bugzilla-daemon | 1 Jan 2009 11:44
Picon

[Bug 16841] Data corruption apparently related to recompressTracked. php on wikis with $wgLegacyEncoding set

https://bugzilla.wikimedia.org/show_bug.cgi?id=16841

Marco <marco <at> harddisk.is-a-geek.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marco <at> harddisk.is-a-geek.org

--- Comment #10 from Marco <marco <at> harddisk.is-a-geek.org>  2009-01-01 10:44:34 UTC ---
You mentioned that the job was partly into dewiki - what about this issue in
de?

--

-- 
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.
Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 Jan 2009 12:08
Picon

[Bug 16811] Text overflows image/table following #mw-revisiontag

https://bugzilla.wikimedia.org/show_bug.cgi?id=16811

--- Comment #4 from Marcin Cieślak <marcin.cieslak <at> gmail.com>  2009-01-01 11:08:10 UTC ---
Created an attachment (id=5636)
 --> (https://bugzilla.wikimedia.org/attachment.cgi?id=5636)
A standard skin screenshot demonstrating the problem

A screenshot to demonstrate the issue. (Standard skin only, on monobook it
looks file)

--

-- 
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 <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
Permalink | Reply | 0 comments |

Gmane