Re: [Wikitech-l] Some suggestions about the edit page.

[Lars Aronsson]

Robert Rohde wrote:
> As I recall, someone did an analysis and reported that people click on
> "edit" more than twice as often as they actually save an edit.

It might be useful to save every "preview" at the server as a
"personal draft", a new version of the the page [[Special:Draft]],
visible only to that user and that only remembers the 100 last
versions of whatever that user previewed (or diffed) during edit.

The performance issue would be small, since the server already
has to handle traffic in and out for each preview.

This would be a low-tech approach to auto-saving, one that
involves the user more and doesn't use any magic background
Javascript.


-- 
  Lars Aronsson (l...@aronsson.se)
  Aronsson Datateknik - http://aronsson.se



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Mobile Wikipedia] 404 for 6 hours

[K. Peachey]

On Thu, Jan 14, 2010 at 1:26 AM, Aryeh Gregor
 wrote:
> Works for me now.
Hampton C. resolved the issue when he work up, The relevant bugzilla
entry for this is #22090 (404 on mobile sites)[1].

[1]. https://bugzilla.wikimedia.org/show_bug.cgi?id=22090

-Peachey

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Some suggestions about the edit page.

[Aryeh Gregor]

On Wed, Jan 13, 2010 at 7:02 PM, Robert Rohde  wrote:
> As I recall, someone did an analysis and reported that people click on
> "edit" more than twice as often as they actually save an edit.  If
> half of all database text were abandoned drafts, that would be dumb.
> Would WMF come tumbling down if the database doubled in size?
> Probably not, but it would still be a dumb use of resources.

Hmm, you might be right, if the drafts are saved too aggressively.
Expiring them after a while would make sense.  Also note, though, that
we can save drafts locally in recent browsers (localStorage is even
supported in IE8) and avoid pushing them to the server often -- I
don't know if Drafts does this or not.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Some suggestions about the edit page.

[Robert Rohde]

On Wed, Jan 13, 2010 at 2:51 PM, Aryeh Gregor
 wrote:
>> I actually like the idea of an autosave, but I could see how it might
>> not be a high priority (and could eventually be something of resource
>> hog if people are allowed to leave a lot of uncommitted drafts lying
>> around).
>
> Resource hog in what sense, disk space?  I don't think disk space is a
> big deal.  You do know that we keep all the old revisions of articles,
> right?  :P

As I recall, someone did an analysis and reported that people click on
"edit" more than twice as often as they actually save an edit.  If
half of all database text were abandoned drafts, that would be dumb.
Would WMF come tumbling down if the database doubled in size?
Probably not, but it would still be a dumb use of resources.
Historically, there has also been opposition to anything that would
allow people to store "private" content on Wikipedia.  Of course both
issues could be dealt with if we just said unsaved drafts expired
after a month or something.

-Robert Rohde

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New Subversion committers

[Platonides]

Tim Starling wrote:
> Chad wrote:
>> I noticed you said "Approved" to Platonides on-wiki but he wasn't
>> mentioned here. Assuming he got it too?
> 
> Yes.
> 
> -- Tim Starling

:)


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Status dashboard creation

[Platonides]

Fred Vassard wrote:
> I was wondering if anybody would have the time to create some sort of 
> application status dashboard, similar to the ones found on google 
> (http://www.google.com/appsstatus#hl=en) or amazon 
> http://status.aws.amazon.com/). 
> Essentially, something that acts like a simplified external facing blog, 
> where people could update the different pieces as problems are detected. 
> Eventually, it would be nice to be able to tie it with our different 
> monitoring softwares, but to begin with, it would be very convenient for our 
> partners to be able to see the overall status of our different layers. For 
> instance, if someone detects that m.wikipedia.org is not working, the first 
> step would be to update said dashboard to inform the less technically-savy 
> people who are not necessarily on IRC of the problem and that someone is 
> looking at it / in the process of fixing it.
> Another important feature would be to keep history on problems that have 
> happened in the past, much like google does. I know this is already done to 
> some extent with the server admin log, but having an easy to read interface 
> would in my opinion prove beneficial.
> 
> Anyway, any suggestion on additional features, or requirements are welcomed. 
> 
> --Fred.

Requirements:
*When the site goes down, the dashboard must still be up, no matter
which layer failed.
*The dashboard must be able to handle the slashdot effect that the site
going down would have on it.

The dashboard would fix bug 20079, forked from 16043.

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


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Some suggestions about the edit page.

[Aryeh Gregor]

On Wed, Jan 13, 2010 at 4:44 PM, Robert Rohde  wrote:
> If there is an autosave type of function, and it is enabled, then one
> could control for duplicate windows using that communication stream.

I don't see how you could reliably detect whether the other window is
still open at the time you raise the warning.  It doesn't seem like it
would be a very common problem, anyway -- most people don't edit so
many pages at once that they wouldn't notice they're editing the same
page twice.  :)

> I actually like the idea of an autosave, but I could see how it might
> not be a high priority (and could eventually be something of resource
> hog if people are allowed to leave a lot of uncommitted drafts lying
> around).

Resource hog in what sense, disk space?  I don't think disk space is a
big deal.  You do know that we keep all the old revisions of articles,
right?  :P

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Status dashboard creation

[Mike.lifeguard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 37-01--10 03:59 PM, Fred Vassard wrote:
> I was wondering if anybody would have the time to create some sort of 
> application status dashboard, similar to the ones found on google 
> (http://www.google.com/appsstatus#hl=en) or amazon 
> http://status.aws.amazon.com/). 
> Essentially, something that acts like a simplified external facing blog, 
> where people could update the different pieces as problems are detected. 
> Eventually, it would be nice to be able to tie it with our different 
> monitoring softwares, but to begin with, it would be very convenient for our 
> partners to be able to see the overall status of our different layers. For 
> instance, if someone detects that m.wikipedia.org is not working, the first 
> step would be to update said dashboard to inform the less technically-savy 
> people who are not necessarily on IRC of the problem and that someone is 
> looking at it / in the process of fixing it.
> Another important feature would be to keep history on problems that have 
> happened in the past, much like google does. I know this is already done to 
> some extent with the server admin log, but having an easy to read interface 
> would in my opinion prove beneficial.
> 
> Anyway, any suggestion on additional features, or requirements are welcomed. 
> 
> --Fred.
> 
> 

There is also http://ezyang.com/wikistatus/ which provides a pretty good
model.

- -Mike
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAktOQGEACgkQst0AR/DaKHv4nACg1x43iE6eEJlK8m/QHn0dgqpj
BpEAoKffuLfaFn/1eQ4VxMvl6w3njqH8
=Hyxf
-END PGP SIGNATURE-

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Some suggestions about the edit page.

[Robert Rohde]

On Wed, Jan 13, 2010 at 7:35 AM, Aryeh Gregor
 wrote:
> On Wed, Jan 13, 2010 at 6:42 AM, Tei  wrote:
>> %% Not multiple edits on same template %%
>>
>> I think the edit  page sould be more smart.   If a user open the same
>> page two times, the second time sould be warned that the page is
>> already opened.  This may need some trans-window comunication, that is
>> not something browser love to do, but I guest is possible with
>> DOMStorage/Cookies or something else.
>
> I don't think there's a reliable way to do this.  We can set some type
> of storage when the user opens an edit page, but we can't reliably
> unset it when they close the page or navigate away.

If there is an autosave type of function, and it is enabled, then one
could control for duplicate windows using that communication stream.
I actually like the idea of an autosave, but I could see how it might
not be a high priority (and could eventually be something of resource
hog if people are allowed to leave a lot of uncommitted drafts lying
around).

> You mean when viewing articles, or editing them?  Cutting out cruft
> when editing is something the usability project is looking into,
> AFAIK.  Cruft while viewing is up to the individual projects, not a
> technical issue -- tell enwiki to use fewer annoying boxes if you
> don't like them.

On the viewing side it isn't be hard to banish the [citation needed]
tags and message boxes using CSS.  I've played around with code for
wiki sites I manage to add that sort of functionality (and other
related options) as a toggle buttons on the sidebar.  I don't know if
putting it in the sidebar for everyone would be okay for enwiki, etc.,
but I'm sure someone could write a gadget to give logged in users the
ability to hide the meta-data.

-Robert Rohde

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Some suggestions about the edit page.

[Roan Kattouw]

2010/1/13 Aryeh Gregor :
> We have this in the Drafts extension, don't we?  I don't know what its
> status is.
>
We at the usability initiative have the intention to integrate that at
some point, but no concrete plans yet AFAICT.

>> %% Un-cruft mode %%
>>
>> There seems to be a lot of "META" information on the wiki, all this
>> metainformation like "stub", etc..  sould be optional.  There must be
>> a single checkbox option to disable it all. I don't want to read even
>> 1 more "citation needed" or "this is a stub"  bloat.  Maybe default
>> sould be to "show cruft".
>
> You mean when viewing articles, or editing them?  Cutting out cruft
> when editing is something the usability project is looking into,
> AFAIK.
We're working on that now, yes.

Roan Kattouw (Catrope)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New Subversion committers

[Michael Dale]

Also just added Michael Shynar ( shmichael ) from Kaltura who is doing 
some add-media-wizard work.

--michael

Tim Starling wrote:
> Bawolff: various Wikinews-related extensions
> Jonathan Williford: extensions developed for http://neurov.is/on
> Ning Hu: Semantic NotifyMe
>
> Rob Lanphier and Conrad Irwin have been added to the core committer group.
>
> -- Tim Starling
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>   


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Status dashboard creation

[Casey Brown]

On Wed, Jan 13, 2010 at 2:57 PM, Fred Vassard  wrote:
> I was wondering if anybody would have the time to create some sort of 
> application status dashboard, similar to the ones found on google 
> (http://www.google.com/appsstatus#hl=en) or amazon 
> http://status.aws.amazon.com/).
>

The toolserver also has something similar: 

> Anyway, any suggestion on additional features, or requirements are welcomed.
>

I don't have any suggestions, but I just want to say that this is a
good idea. :-)

-- 
Casey Brown
Cbrown1023

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Status dashboard creation

[Fred Vassard]

I was wondering if anybody would have the time to create some sort of 
application status dashboard, similar to the ones found on google 
(http://www.google.com/appsstatus#hl=en) or amazon 
http://status.aws.amazon.com/). 
Essentially, something that acts like a simplified external facing blog, where 
people could update the different pieces as problems are detected. Eventually, 
it would be nice to be able to tie it with our different monitoring softwares, 
but to begin with, it would be very convenient for our partners to be able to 
see the overall status of our different layers. For instance, if someone 
detects that m.wikipedia.org is not working, the first step would be to update 
said dashboard to inform the less technically-savy people who are not 
necessarily on IRC of the problem and that someone is looking at it / in the 
process of fixing it.
Another important feature would be to keep history on problems that have 
happened in the past, much like google does. I know this is already done to 
some extent with the server admin log, but having an easy to read interface 
would in my opinion prove beneficial.

Anyway, any suggestion on additional features, or requirements are welcomed. 

--Fred.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Some suggestions about the edit page.

[Tei]

2010/1/13 Robert Leverington :
> On 2010-01-13, Tei wrote:
>> %% The Death of Wiki %%
...
>> you can't stop that, you can code something so the resulting dead body
>> of wiki is not pure shit.   A possible idea could be to "auto-protect"
>> pages without edit in N years (4 years),
...
>
> The AbsenteeLandlord extension may fulfil this to a certain extent. [1]
>
> [1] http://www.mediawiki.org/wiki/Extension:AbsenteeLandlord
>

I am happy, I am not the first one to think about these issues.


-- 
--
ℱin del ℳensaje.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Some suggestions about the edit page.

[Robert Leverington]

On 2010-01-13, Tei wrote:
> %% The Death of Wiki %%
> 
> Ultimatelly, al wikis lose the war against entropy and are abandoned.
> This will hit all wikipedia wikis, and all based on mediawiki.  While
> you can't stop that, you can code something so the resulting dead body
> of wiki is not pure shit.   A possible idea could be to "auto-protect"
> pages without edit in N years (4 years), and save id of the "last know
> good version", this can be done flagging the pages as "dirty" after a
> edit, and flag pages as "clean" wen a logged editor say so.  Something
> like "Page Milestones".  Maybe the "History" view of a page sould list
> first the last 10 milestones (newer first), then the "dump" of all
> edits. There are probably about more than 10 years to think about this
> issue.
>

The AbsenteeLandlord extension may fulfil this to a certain extent. [1]

[1] http://www.mediawiki.org/wiki/Extension:AbsenteeLandlord

Robert 


signature.asc
Description: Digital signature
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Some suggestions about the edit page.

[Aryeh Gregor]

On Wed, Jan 13, 2010 at 6:42 AM, Tei  wrote:
> %% Not multiple edits on same template %%
>
> I think the edit  page sould be more smart.   If a user open the same
> page two times, the second time sould be warned that the page is
> already opened.  This may need some trans-window comunication, that is
> not something browser love to do, but I guest is possible with
> DOMStorage/Cookies or something else.

I don't think there's a reliable way to do this.  We can set some type
of storage when the user opens an edit page, but we can't reliably
unset it when they close the page or navigate away.

> %% Autosave feature for edit %%
>
> Again, in this day and age,  losing data because a computer crash is a
> problem that sould never ocurr.  The edit page sould save the latest
> version of the edited text to a local persistent area ( DOMStorage? ).
>  That way, I can 'accidentally close' the edit page, and wen I reopen
> the edit, the page sould detect "He.. the page is on the same
> revision, this mean my edited version is interesting", and let the
> user continue editing.  "You closed the edit page withouth saving. Do
> you want to continue with the old version?".   Somewhat like the
> "drafts" feature on gmail, or the autosave feature of OpenOffice.

We have this in the Drafts extension, don't we?  I don't know what its
status is.

> %%  Edit in the browser any fileformat  wen webeditors for such
> fileformats are available %%
>
> Wen possible,  documents sould be editable inside the browser. This
> mean as possible, add a SVG editor or a Math editor or a HTML editor
> or a DOC editor or a PNG editor.    The   PNG is wrong -> download ->
> edit -> upload  is lame.  The  PNG is wrong -> edit -> save is cool.
>
> The current edit page only supports wikicode :-(

This has been talked about before, and would be nice to have, but I
don't think there are any polished solutions available right now.

> %% Un-cruft mode %%
>
> There seems to be a lot of "META" information on the wiki, all this
> metainformation like "stub", etc..  sould be optional.  There must be
> a single checkbox option to disable it all. I don't want to read even
> 1 more "citation needed" or "this is a stub"  bloat.  Maybe default
> sould be to "show cruft".

You mean when viewing articles, or editing them?  Cutting out cruft
when editing is something the usability project is looking into,
AFAIK.  Cruft while viewing is up to the individual projects, not a
technical issue -- tell enwiki to use fewer annoying boxes if you
don't like them.

> %% Wikipedia Green, Blue and Orange %%
>
>  A way to fight Deletionism, could be to have something like
> "different levels" on the wikipedia (a wiki).   Set a group of pages
> on "Book Blue", for pages with a maintainer, and pages approved by a
> superior committee of quality. Set a group of pages on "Green Book"
> for pages that serve the merits of notability.  "Yellow Book" for
> pages that don't fulfill a notability criteria.  Deletionism is
> binary,  computers can work with more values than 1, 0.     Hell.. you
> can make Green Book and Yellow Book invisible for the un-loged users,
> only available for loged users.  For this thing to work, Templates
> sould use different colors for differents books.   Colors will also
> account for quality. The german will be mostly blue, while others will
> have more green pages. There will be a wiki with 90.000 green and
> 10.000 blue. And other one with 10.000 green and 90.000 blue.

This would need to be requested by a particular community.  We can't
force people to keep pages they want to delete.

> %% The Death of Wiki %%
>
> Ultimatelly, al wikis lose the war against entropy and are abandoned.
> This will hit all wikipedia wikis, and all based on mediawiki.  While
> you can't stop that, you can code something so the resulting dead body
> of wiki is not pure shit.   A possible idea could be to "auto-protect"
> pages without edit in N years (4 years), and save id of the "last know
> good version", this can be done flagging the pages as "dirty" after a
> edit, and flag pages as "clean" wen a logged editor say so.  Something
> like "Page Milestones".  Maybe the "History" view of a page sould list
> first the last 10 milestones (newer first), then the "dump" of all
> edits. There are probably about more than 10 years to think about this
> issue.

I don't share your pessimism on this issue.  But in any event, it
would be easy to do this after the fact, since we keep all history, so
we don't need to worry about it until it's actually happened.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Mobile Wikipedia] 404 for 6 hours

[Aryeh Gregor]

On Wed, Jan 13, 2010 at 4:18 AM, Christophe Henner
 wrote:
> I've just been notified that http://m.wikipedia.org is 404 for hours.

Works for me now.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New Subversion committers

[Tim Starling]

Chad wrote:
> On Tue, Jan 12, 2010 at 11:54 PM, Tim Starling  
> wrote:
>> Bawolff: various Wikinews-related extensions
>> Jonathan Williford: extensions developed for http://neurov.is/on
>> Ning Hu: Semantic NotifyMe
>>
>> Rob Lanphier and Conrad Irwin have been added to the core committer group.
>>
>> -- Tim Starling
>>
>>
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
> 
> I noticed you said "Approved" to Platonides on-wiki but he wasn't
> mentioned here. Assuming he got it too?

Yes.

-- Tim Starling


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New Subversion committers

[Chad]

On Tue, Jan 12, 2010 at 11:54 PM, Tim Starling  wrote:
> Bawolff: various Wikinews-related extensions
> Jonathan Williford: extensions developed for http://neurov.is/on
> Ning Hu: Semantic NotifyMe
>
> Rob Lanphier and Conrad Irwin have been added to the core committer group.
>
> -- Tim Starling
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

I noticed you said "Approved" to Platonides on-wiki but he wasn't
mentioned here. Assuming he got it too?

-Chad

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Some suggestions about the edit page.

[Tei]

%% Not multiple edits on same template %%

I think the edit  page sould be more smart.   If a user open the same
page two times, the second time sould be warned that the page is
already opened.  This may need some trans-window comunication, that is
not something browser love to do, but I guest is possible with
DOMStorage/Cookies or something else.

%% Autosave feature for edit %%

Again, in this day and age,  losing data because a computer crash is a
problem that sould never ocurr.  The edit page sould save the latest
version of the edited text to a local persistent area ( DOMStorage? ).
 That way, I can 'accidentally close' the edit page, and wen I reopen
the edit, the page sould detect "He.. the page is on the same
revision, this mean my edited version is interesting", and let the
user continue editing.  "You closed the edit page withouth saving. Do
you want to continue with the old version?".   Somewhat like the
"drafts" feature on gmail, or the autosave feature of OpenOffice.

%%  Edit in the browser any fileformat  wen webeditors for such
fileformats are available %%

Wen possible,  documents sould be editable inside the browser. This
mean as possible, add a SVG editor or a Math editor or a HTML editor
or a DOC editor or a PNG editor.The   PNG is wrong -> download ->
edit -> upload  is lame.  The  PNG is wrong -> edit -> save is cool.

The current edit page only supports wikicode :-(

%% Un-cruft mode %%

There seems to be a lot of "META" information on the wiki, all this
metainformation like "stub", etc..  sould be optional.  There must be
a single checkbox option to disable it all. I don't want to read even
1 more "citation needed" or "this is a stub"  bloat.  Maybe default
sould be to "show cruft".

%% Wikipedia Green, Blue and Orange %%

 A way to fight Deletionism, could be to have something like
"different levels" on the wikipedia (a wiki).   Set a group of pages
on "Book Blue", for pages with a maintainer, and pages approved by a
superior committee of quality. Set a group of pages on "Green Book"
for pages that serve the merits of notability.  "Yellow Book" for
pages that don't fulfill a notability criteria.  Deletionism is
binary,  computers can work with more values than 1, 0. Hell.. you
can make Green Book and Yellow Book invisible for the un-loged users,
only available for loged users.  For this thing to work, Templates
sould use different colors for differents books.   Colors will also
account for quality. The german will be mostly blue, while others will
have more green pages. There will be a wiki with 90.000 green and
10.000 blue. And other one with 10.000 green and 90.000 blue.

%% The Death of Wiki %%

Ultimatelly, al wikis lose the war against entropy and are abandoned.
This will hit all wikipedia wikis, and all based on mediawiki.  While
you can't stop that, you can code something so the resulting dead body
of wiki is not pure shit.   A possible idea could be to "auto-protect"
pages without edit in N years (4 years), and save id of the "last know
good version", this can be done flagging the pages as "dirty" after a
edit, and flag pages as "clean" wen a logged editor say so.  Something
like "Page Milestones".  Maybe the "History" view of a page sould list
first the last 10 milestones (newer first), then the "dump" of all
edits. There are probably about more than 10 years to think about this
issue.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] [Mobile Wikipedia] 404 for 6 hours

[Christophe Henner]

Hi,

I've just been notified that http://m.wikipedia.org is 404 for hours.

Can anyone check this out ?

-- 
Christophe

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l