bugzilla | 1 Jan 01:09 2008
Picon

[Bug 4582] Provide preference-based autoformatting for unlinked dates

http://bugzilla.wikimedia.org/show_bug.cgi?id=4582

--- Comment #93 from Omegatron <l8qjvx002@...>  2008-01-01
00:09:20 UTC ---
(In reply to comment #91)
> To me it makes a lot more sense that if an editor wants magic to happen, they
> should ask for magic.

And we should remove the auto-linking of ISBN numbers, because there are a few
cases where they should not link to the Book sources page.  See
http://en.wikipedia.org/wiki/International_Standard_Book_Number#Check_digit_in_ISBN-10
for example.

Oh, and we should also remove the auto-linking of URLs, because sometimes
people want them to just be written out without actually becoming a link.  See
http://en.wikipedia.org/wiki/URL_normalization#Normalization_process for some
examples.

And we should remove the auto-linking of RFC numbers, since there are some
cases where this conflicts and people don't want an actual link.  See ... well,
I can't find any examples.  But I'm sure there are a few cases where people
don't want them to be linked.

We certainly don't want to confuse users by linking these things every time,
when they should only be links 99.9% of the time.  Users should have to
explicitly spell out what they want with special tags, since we certainly don't
want to make assumptions about what they want.  Let's call it an "a" tag, for
"Anchor", and then we'll have the link text inside the tags, with a URL which
we'll label "href" for "Hypertext REFerence", ...

(Continue reading)

bugzilla | 1 Jan 01:37 2008
Picon

[Bug 12466] New: Disable upload on it.wiktionary for non sysop users

http://bugzilla.wikimedia.org/show_bug.cgi?id=12466

           Summary: Disable upload on it.wiktionary for non sysop users
           Product: Wikimedia
           Version: unspecified
          Platform: All
               URL: http://it.wiktionary.org/wiki/Wikizionario:Bar#Upload
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: Normal
         Component: General/Unknown
        AssignedTo: wikibugs-l@...
        ReportedBy: federicoleva@...

As decided in the url above, please disable uploads on it.wiktionary, except
that for sysops.
Thanks,
Nemo

--

-- 
Configure bugmail: http://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.
bugzilla | 1 Jan 01:57 2008
Picon

[Bug 4582] Provide preference-based autoformatting for unlinked dates

http://bugzilla.wikimedia.org/show_bug.cgi?id=4582

--- Comment #94 from Tony Souter <tony1 <at> iinet.net.au>  2008-01-01 00:57:06 UTC ---
Automatically rendering ISO-formatted dates as autoformatted would need to be
turned off. Autoformatting doesn't work with date ranges (3–7 January 2010,
the way MOS says to format such a range), nor slashed dates (night of 3/4
July). I guess you'd just write these ranged/slashed items in raw form without
any auto.

--

-- 
Configure bugmail: http://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l <at> lists.wikimedia.org
http://lists.wikimedia.org/mailman/listinfo/wikibugs-l
bugzilla | 1 Jan 02:48 2008
Picon

[Bug 12467] New: Show only other people's edits on Special:Contributions

http://bugzilla.wikimedia.org/show_bug.cgi?id=12467

           Summary: Show only other people's edits on Special:Contributions
           Product: Wiktionary tools
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: Normal
         Component: General
        AssignedTo: wikibugs-l@...
        ReportedBy: hippytrail@...

I often want to see how articles I've edited have changed since I edited them,
whether or not they are on my Watchlist.

Special:Contributions shows my most recent edits but it is difficult to
visually filter my own edits from those of other editors. A little tool to hide
all of the entries with <b>(top)</b> would be very helpful.

Additionally it would be good to hide all links to edits prior to one I made.

--

-- 
Configure bugmail: http://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.
bugzilla | 1 Jan 07:35 2008
Picon

[Bug 12452] Mod of Uploading Interface to encourage copyright compliance

http://bugzilla.wikimedia.org/show_bug.cgi?id=12452

Mbisanz <mattbisanz@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mattbisanz@...

--

-- 
Configure bugmail: http://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
bugzilla | 1 Jan 11:55 2008
Picon

[Bug 12467] Show only other people's edits on Special:Contributions

http://bugzilla.wikimedia.org/show_bug.cgi?id=12467

Andrew Dunbar <hippytrail@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://en.wiktionary.org/wik
                   |                            |i/User:Hippietrail/filtercon
                   |                            |tribs.js

--- Comment #1 from Andrew Dunbar <hippytrail@...>  2008-01-01
10:55:22 UTC ---
I've implemented this in JavaScript:
http://en.wiktionary.org/wiki/User:Hippietrail/filtercontribs.js

It does not yet have a button or link to turn it on or off. I would prefer to
do this with CSS classes but it might be easier to do dynamically with
JavaScript functions.

--

-- 
Configure bugmail: http://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.
bugzilla | 1 Jan 13:33 2008
Picon

[Bug 8554] High-precision block times are misinterpreted as time of day and duration

http://bugzilla.wikimedia.org/show_bug.cgi?id=8554

Huji <huji.huji@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |huji.huji@...
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #2 from Huji <huji.huji@...>  2008-01-01 12:33:58
UTC ---
Here is what goes on:

The value of the "Other time:" box in Special:Blockip page (a text input named
wpBlockOther) is passed to strtotime() to function on line 371 of
SpecialBlockip.php (as of revision 27807). It is strtotime() which
misinterprets the number indeed. See:

strtotime("2 weeks")         returns   1200400424
strtotime("3 weeks")         returns   1201005224
strtotime("2.37685 weeks")   returns   1613443020

So indeed, this is a bug of PHP's strtotime function (or, if not a bug, it is
at least a bad way to use it, because in PHP documentation it is clearly stated
that strtotime() expects date to be i GNU format, while "2.37685 weeks" is not
in GNU format per
http://www.gnu.org/software/tar/manual/html_chapter/tar_7.html).

Anyways, at this is not a MediaWiki bug, I'm marking it as INVALID.
(Continue reading)

bugzilla | 1 Jan 13:55 2008
Picon

[Bug 8440] Allow preventing blocked users from editing their talk pages ( case-by-case basis when $wgBlockAllowsUTEdit = true)

http://bugzilla.wikimedia.org/show_bug.cgi?id=8440

Huji <huji.huji@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |huji.huji@...

--- Comment #15 from Huji <huji.huji@...>  2008-01-01 12:55:50
UTC ---
I don't agree this is a useful feature. When an admin is blocking a user, how
can he know (forsee) that the user will abuse his talk page? If it turns out
that the user is abusing his talk page, which is the better solution: To
unblock and reblock with that option checked, or to protect the talk page?

The only situation where such a feature may be useful is when an admin is
blocking a user for a second+ time (or a second account of a known vandal), and
knows for certain that this person has had a history of abusing talk pages. I
think this is a really rare event, and doesn't justify adding such a feature.

--

-- 
Configure bugmail: http://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.
bugzilla | 1 Jan 14:18 2008
Picon

[Bug 12145] Kazakh message updates

http://bugzilla.wikimedia.org/show_bug.cgi?id=12145

AlefZet <alefzet@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
Attachment #4486 is|0                           |1
           obsolete|                            |

--- Comment #29 from AlefZet <alefzet@...>  2008-01-01
13:18:50 UTC ---
Created an attachment (id=4487)
 --> (http://bugzilla.wikimedia.org/attachment.cgi?id=4487)
Patch for MediaWiki

Updates

--

-- 
Configure bugmail: http://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.
bugzilla | 1 Jan 14:19 2008
Picon

[Bug 12145] Kazakh message updates

http://bugzilla.wikimedia.org/show_bug.cgi?id=12145

AlefZet <alefzet@...> changed:

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

--

-- 
Configure bugmail: http://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.

Gmane