headers
Mark A. Hershberger | 1 Dec 2011 01:00
Picon

Re: 1.18 issues triage

Chad <innocentkiller <at> gmail.com> writes:

> Also we should probably fix the StartProfiler regression.

I don't see a bug for this.  Could you file one?

Or, if there is one that I've missed, could you make Bug #32711 depend
on it?

Thanks,

Mark.
Permalink | Reply | 0 comments |
headers
Brion Vibber | 1 Dec 2011 01:48
Picon
Favicon
Gravatar

Re: Who actually reads <at> wikimediatech ?

On Wed, Nov 30, 2011 at 3:49 PM, Platonides <Platonides <at> gmail.com> wrote:

> On 30/11/11 00:53, Brion Vibber wrote:
> > It would be fairly trivial to whip up a script that pushes to the
> > identi.caaccount and has its own authentication. It might even -- dare
> > I say it --
> > be a MediaWiki plugin using our existing authentication and user groups
> > system. :)
>
> That was my Plan B, but thought that perhaps it was already handled
> upstream.
> AFAIK that mw extension would also be useful for some communities.
>

I stuck an entry into the 'extension requests' section on bz:
https://bugzilla.wikimedia.org/show_bug.cgi?id=32745

If anybody feels like working on such a tool or commenting on its
usefulness, there's the place. :D

-- brion
Permalink | Reply | 0 comments |
headers
Brion Vibber | 1 Dec 2011 01:54
Picon
Favicon
Gravatar

Re: Quick Mumbai hackathon followup

On Wed, Nov 30, 2011 at 11:22 AM, Lars Aronsson <lars <at> aronsson.se> wrote:

> On 11/30/2011 05:03 PM, Brion Vibber wrote:
> > I'm quite intrigued by the on-screen keyboard for the Narayam input
> method.
> > I haven't seen it in action, but the screenshots look nice -- it's
> showing
> > what chars would get typed and you can click on them directly or use it
> as
> > a guide for the physical keyboard. Sweet!
>
> When editing Wikipedia articles or proofreading in Wikisource,
> the number of possible character sets that you can want to
> pick characters from makes it hard to design a nice user interface.
> I think it could help if the characters in the existing article
> were used.
>
> For example, when editing an article on Moscow, if Cyrillic
> names of suburbs are mentioned in the article, the Cyrillic
> characters would appear in the editing interface (but not
> Greek, Arabic or Japanese).
>

+1 context-sensitivity can be a big help in these things.

Detecting presence of certain languages on the page and making sure their
special keyboards or symbols are available (but not in your way until you
need them) would be a big assistance for working on some pages!

-- brion
(Continue reading)

Permalink | Reply | 0 comments |
headers
Aaron Schulz | 1 Dec 2011 02:51
Picon

FileBackend branch


I'm starting to finish the initial coding for the FileBackend branch (see
https://svn.wikimedia.org/viewvc/mediawiki/branches/FileBackend). I still
have to get to thumb.php and img_auth.php though. Simple testing of uploads,
re-uploads, moves, deletes, restores, and such are working on my local
testwiki.

At some point, I'll need to merge all this into /trunk of course. I'd
appreciate any help in:
* Downloading the code and playing around with it
* Finding extensions that will need updating (or functionality that needs to
be added to core for them)
* Making suggestions and pointing out broken stuff (which I'm sure there is
lots of)
* Writing test cases (a LOT of these will be needed)
* i18n improvements/docs for messages
--

-- 
View this message in context: http://old.nabble.com/FileBackend-branch-tp32887504p32887504.html
Sent from the Wikipedia Developers mailing list archive at Nabble.com.
Permalink | Reply | 5 comments |
headers
Rob Lanphier | 1 Dec 2011 04:20
Picon
Gravatar

Re: FileBackend branch

On Wed, Nov 30, 2011 at 5:51 PM, Aaron Schulz <aschulz4587 <at> gmail.com> wrote:
> I'm starting to finish the initial coding for the FileBackend branch (see
> https://svn.wikimedia.org/viewvc/mediawiki/branches/FileBackend). I still
> have to get to thumb.php and img_auth.php though. Simple testing of uploads,
> re-uploads, moves, deletes, restores, and such are working on my local
> testwiki.

Hi folks,

A few more details on this.  Aaron is trying to get some important
refactoring work done in service to this project:
http://www.mediawiki.org/wiki/SwiftMedia

We'd like to land this code in trunk as soon as we can, shake out the
inevitable bugs, and get this rolled out to the cluster as part of
1.19.  That will then make it possible for us to complete the
migration from NFS as our file storage tech to Swift.  That in turn
will enable us to greatly expand our file capacity on commons, as well
as making it so that we no longer have a scary single point of failure
for file storage on the Wikimedia cluster.

Rob
Permalink | Reply | 3 comments |
headers
Erik Moeller | 1 Dec 2011 05:27
Picon
Gravatar

UI prototypes from Mumbai

Shivansh Shrivastava developed these mockups which he presented at the
WikiConference India and shared with me at the Mumbai hackathon:

https://svn.wikimedia.org/viewvc/mediawiki/trunk/mockups/ajax-mockups/

* English Wikipedia main page mockup with newsticker and gallery
* Sliding login/account creation panel (based on existing GPL'd jQuery plugin)
* Floating table of contents tab

Some interesting ideas there, I'm sure he'd welcome any comments
on-list or off-list :-)

--

-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Permalink | Reply | 3 comments |
headers
Russell Nelson | 1 Dec 2011 05:54
Picon
Gravatar

Re: FileBackend branch

On Wed, Nov 30, 2011 at 10:20 PM, Rob Lanphier <robla <at> wikimedia.org> wrote:

> On Wed, Nov 30, 2011 at 5:51 PM, Aaron Schulz <aschulz4587 <at> gmail.com>
> wrote:
> > I'm starting to finish the initial coding for the FileBackend branch (see
> > https://svn.wikimedia.org/viewvc/mediawiki/branches/FileBackend). I
> still
> > have to get to thumb.php and img_auth.php though. Simple testing of
> uploads,
> > re-uploads, moves, deletes, restores, and such are working on my local
> > testwiki.
>

Did you test it using smtest.py ? It's a lot more persistent about testing
because it's a lot less distractable than any hu .... SQUIRREL!

> Hi folks,
>
> A few more details on this.  Aaron is trying to get some important
> refactoring work done in service to this project:
> http://www.mediawiki.org/wiki/SwiftMedia
>
> We'd like to land this code in trunk as soon as we can, shake out the
> inevitable bugs, and get this rolled out to the cluster as part of
> 1.19.
>
>
I'm guessing that Aaron is coding using an IDE that displays abstract class
comments in line with the implementation, because the implementation class
has no comments on any of the methods. For those of us using dumber
(Continue reading)

Permalink | Reply | 2 comments |
headers
Brion Vibber | 1 Dec 2011 17:42
Picon
Favicon
Gravatar

Re: UI prototypes from Mumbai

On Wed, Nov 30, 2011 at 8:27 PM, Erik Moeller <erik <at> wikimedia.org> wrote:

> Shivansh Shrivastava developed these mockups which he presented at the
> WikiConference India and shared with me at the Mumbai hackathon:
>
> https://svn.wikimedia.org/viewvc/mediawiki/trunk/mockups/ajax-mockups/
>
> * English Wikipedia main page mockup with newsticker and gallery
>

I'm not too fond of moving tickers like this; it's a bit distracting, but
it's also an accessibility issue: some people may have a hard time getting
at that text because it's moving around.

The gallery is more intriguing; we definitely need better support for
showing sets of nice pictures, and something in that direction would be
very nice in a number of places.

Again, automatically shifting through them can be an accessibility issue,
so shouldn't be generally relied upon but can be good for autoplay-style
stuff as long as you can pause it easily and navigate manually.

* Sliding login/account creation panel (based on existing GPL'd jQuery
> plugin)
>

This looks super cool! Main practical problem with an ajax login form is
that we'd like to migrate all logins over to SSL (required, not optional)
somewhere in the medium-term.
(Continue reading)

Permalink | Reply | 1 comment |
headers
William Lee | 1 Dec 2011 18:34
Favicon

Proposal for new table image_metadata

I'm a developer at Wikia. We have a use case for searching through a file's
metadata. This task is challenging now, because the field
Image.img_metadata is a blob.

We propose expanding the metadata field into a new table. We propose the
name image_metadata. It will have three columns: img_name, attribute
(varchar) and value (varchar). It can be joined with Image on img_name.

On the application side, LocalFile's load* and decodeRow methods will have
to be changed to support the new table.

One issue to consider is the file archive. Should we replicate the metadata
table for file archive? Or serialize the data and store it in a new table
(something like fa_metadata)?

Please let us know if you see any issues with this plan. We hope that this
will be useful to the MediaWiki project, and a candidate to merge back.

Thanks,
Will
Permalink | Reply | 11 comments |
headers
David Gerard | 1 Dec 2011 18:36
Picon
Gravatar

Re: Proposal for new table image_metadata

On 1 December 2011 17:34, William Lee <wlee <at> wikia-inc.com> wrote:

> I'm a developer at Wikia. We have a use case for searching through a file's
> metadata. This task is challenging now, because the field
> Image.img_metadata is a blob.

This sounds a natural for Commons, too.

- d.
Permalink | Reply | 0 comments |

Gmane