Interesting..... users/developers comment on the inclusion of reCATCHPA
within the fund-raising[1] code since other projects have been they can't
utilize its services then ~two weeks later (which isn't all that long in wmf
time) its project documentation is moved off wiki (mw wiki) into the
office[2] wiki which is private to WMF staff members only....
I will let everybody think about that.
[1]. http://www.mediawiki.org/wiki/Special:Code/MediaWiki/70919
[2].
http://www.mediawiki.org/w/index.php?title=Payment_Fraud_Prevention&action=…
As you all know, the installer was rewritten recently. Step-by-step
wizard, JS magic, UI for configuration options that previously had
to be manually changed in LocalSettings, in-place upgrades, you
name it.
However, there's one thing about it that needs YOUR help:
translations. The new installer (at last!) has localisable interface,
and it needs translations to be usable to more people around the
world. However, from my experience with installer translations:
* Most translators are non-techies, they have problems with long
messages full of that weird IT lingo.
* Things are bad when translators avoid translating a message because
they don't understand it. Things get much, much worse if they think
that they know how to translate them, but in reality they're wrong.
* While simple users usually can take a look at wiki to have an idea
how things work, this is not an option with the installer. Some messages
may therefore be translated out of context.
So those of you who are proficient in languages other than English -
YOU can make a difference. Go to http://translatewiki.net and start
translating. If there are already some translations in your language,
double-check them - I assure you, there will be things to fix. Once
everything is complete, try running the installer a few times,
covering as many execution paths as you can - there will be things to
fix.
This way, we can ensure much better localisation. Oh, and forgive me my
propagandist style - I couldn't help myself :)
--
Max Semenik ([[User:MaxSem]])
This extension received no significant updates for the last 5 years
and doesn't work with anything newer than 1.4. It doesn't even have a
description page on mw.org. Nevertheless, numerous developers
was^H^H^H spent their time on it while doing batch improvements to
the whole extensions directory.
Is someone interested in reviving it, or we can delete it right away?
--
Max Semenik ([[User:MaxSem]])
* Michael Dale <mdale(a)wikimedia.org> [Sat, 13 Nov 2010 17:08:50 +0100]:
> On 11/10/2010 05:53 PM, Dmitriy Sintsov wrote:
> >
> > As Roan have pointed out, local messages don't need a complete
parser
> > anyway. I hope you have the time to merge it, if so can you announce
> > that, please?
> > Dmitriy
>
> The bug has been updated with a patch. Some integration notes are in
the
> bug comment.
>
Thank you a lot. I'll update from trunk and try to use it client-side in
my extension.
Dmitriy
* Michael Dale <mdale(a)wikimedia.org> [Wed, 10 Nov 2010 17:20:26 +0100]:
> The code is not spread across many files.. its a single mw.Parser.js
> file. Its being used in my gadget and Neil's upload wizard. I agree
> the parser is not the "ideal parser", its not feature complete, is not
> very optimised, and it was hacked together quickly. But it passes all
> the tests and matches the output of php for all the messages across
all
> the languages. I should have time in the next few days to re merge /
> clean it up a bit if "no one else" is doing it.
>
As Roan have pointed out, local messages don't need a complete parser
anyway. I hope you have the time to merge it, if so can you announce
that, please?
Dmitriy
We just had a discussion in #mediawiki about this commit:
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/76064
It removed wfLoadExtensionMessages() from dozens of extensions in
trunk. With trunk MediaWiki, this causes no problems, since the
function does nothing. But in older MediaWiki versions, it will cause
the extension to break. Yaron reported that he quickly got a
complaint from someone using one of his trunk extensions together with
MediaWiki 1.15.
This kind of thing has come up before, e.g., the removal of IE5
support from Monobook. My take on this is that the cost-benefit
analysis is very simple:
* Cost to users of removing wfLoadExtensionMessages() from trunk
extensions: If the extension happened to work on some old MW version
(some do), the extension breaks.
* Benefit to users of removing wfLoadExtensionMessages() from trunk
extensions: Nothing. Extension works the same as before, no better or
worse.
I think it's very clear that in cases like this, we should not remove
back-compat. If there's some benefit, then maybe -- for instance, if
the code is hard to maintain, that could outweigh back-compat
benefits. But this code isn't hard to maintain at all, it's one line
in each extension. If there's no cost, then sure -- for instance, if
the extension already only works on trunk for some other reason (maybe
a new feature was added that uses a trunk function), then no harm is
caused by removing the back-compat lines.
But going out of your way to remove back-compat when that will hurt
some users and not ease development *quantifiably* does not make any
sense, and IMO no one should be doing that. ("Quantifiably" means
"I'm not going to bother adding new feature X if I have to maintain
back-compat while doing it", not "I think the code is uglier".) We
can disagree about how much work we need to go into to maintain
back-compat, but it's not *negative* -- putting work into removing
back-compat without clear gain does not make sense.
I've created a page on mediawiki.org to set out some guidelines we can
consider: <http://www.mediawiki.org/wiki/Backward_compatibility>. I
think we should get something written down that we can agree on, since
this issue has come up more than once before and the same people tend
to repeat the same disagreements every time.
