Hi,
The JSON i18nj files in MediaWiki extensions are getting filled by apihelp
messages. They are usually added to the end of the files.
In addition to docs internationalization, which is pretty awesome by
itself, this happens to have another somewhat useful side effect on the
i18n files
On Sat, Nov 8, 2014 at 4:29 AM, Amir E. Aharoni
amir.ahar...@mail.huji.ac.il wrote:
Keeping the apihelp messages in the end and adding all other messages
before them prevents this comma-adding and shortens the diff by one line.
It is, of course, a small thing, but it saves a few moments when
OTOH, you're likely to get the same effect by sorting the i18n files by
key
(which I recently learned some teams enforce), since it's not that common
that you add a new message alphabetically after every other message in the
file.
Sorting alphabetically by key seems rather pointless to me,
+1 for disabling CAPTCHs (at least in signup form).
Anyway, sysops already have enougth tools for treating abuse by spam bots
using AbuseFilter (e.g with rate filter).
On Sat, Nov 8, 2014 at 12:19 AM, MZMcBride z...@mzmcbride.com wrote:
Tim Starling wrote:
On 07/11/14 19:17, svetlana wrote:
We seem to really gravitate towards complexity on these things. How can we
make them simple, addressing a very specific need. We can complicate later.
Here is a scenario (which we should start with, not architecture)
1. As an editor I'd like to flag a revision as reviewed/verified by me
One session I really looked forward to at the Wikimania was the one on
Visual Editor and the talk on RealTime Editing (the one presented by Erik).
Of course, I enjoyed, seeing some of the nice future goals of how realtime
editing could be possible, however with very strong huddles to overcome.
Honestly i dont think anyone's even tried to improve the conflict screen.
There's probably a lot of low hanging fruit on the usability of edit
conflicts which could be persued that have nothing to do with the hard,
real time editing solutions (as cool as those are).
If someone is intrested in
Looked for it and found this doc on it:
http://codex.wordpress.org/Post_Locking
Your points are also valid, at least far better than the current diff
system which isn't that easy to understand what is actually going on or
whatnot.
On Nov 8, 2014 10:01 PM, Brian Wolff bawo...@gmail.com wrote:
The fact that no one has even tried improving the conflict issue in
simplest way possible for years now is even something a bit strange.
On Nov 8, 2014 10:01 PM, Brian Wolff bawo...@gmail.com wrote:
Honestly i dont think anyone's even tried to improve the conflict screen.
There's probably a lot
The second release candidate for 1.24.0 (1.24.0-rc.1) is now available for
download.
The changes since 1.24.0-rc.0 are as follows:
* (bug 70686) More sensible behavior when special page aliases conflict.
* (bug 71040) Add Oracle version of update-keys.sql.
* (bug 64912, 64922) mw.Title: Add
It might be worth asking the Editing team if improving the handling of edit
conflicts is something that they have on their agenda or if they can add it
next to their agenda for the next FY, or if this project would be a good
GSOC/OPW project. James, can you comment? I know you're busy with VE and
On Fri, Nov 7, 2014 at 2:19 PM, MZMcBride z...@mzmcbride.com wrote:
I think that's unfair.
Wikis have a serious spam problem. People associate CAPTCHAs with spam
prevention. On the English Wikipedia, one of the actions that results in
the user being required to successfully enter a CAPTCHA
For some more background, when we proposed something like that to Chris
Steipp he was pretty iffy about it, and he's not wrong. At other sites
that
don't have a CAPTCHA on signup (like Facebook, Quora, others) they avoid a
spam problem in part because they require an email address and
I suspect it isn't done because it isn't a very good way to modify a
complex embedded base of software, Lila. Generally, when modifying a
complex embedded base, one designs first, iterates implementation and
internal testing, and then releases a relatively complete piece of
functionality.
Hey Erik,
I'm glad to see that we're imagining similar things. :) This project has
been on my to-do list for years.
I don't think that building a well-designed service and starting in labs
are conflicting options. Regardless this project is marching forward in
the next couple of months. I
Umm. No. If ever you want major pushback from the broad international
community, requiring any kind of documentation to open an account will
probably work very well. I certainly would never have signed up for an
account on Wikipedia if I'd had to supply an email address.
Risker/Anne
On 9
Hey,
I suspect it isn't done because it isn't a very good way to modify a
complex embedded base of software, Lila. Generally, when modifying a
complex embedded base, one designs first, iterates implementation and
internal testing, and then releases a relatively complete piece of
We're talking about a test, not a broad rollout (:
I'm curious, Risker: if you don't mind my asking, what about being required
to supply a throwaway email address would have discouraged you from opening
a Wikimedia account?
Pine
___
Wikitech-l mailing
18 matches
Mail list logo
