All,
I've been working the last 24 hours or so on improving the ForeignAPI code that
Brion committed a little while back. I've implemented some rather
effective caching
that has gotten thumbs and remote description pages cached locally (by setting
$wgForeignFileRepos['useLocalCache'] to true). Also,
$wgForeignFileRepos['localCacheExpiry'] is used to set the explicit
expiry time for
local copies of thumbs/description pages. There's only two things left
really that
I see need doing:
1) One last Http::get().is still used on every request to fetch the
remote image
metadata. On the one hand, it would be nice to cache this, as then we could
eliminate the last Http::get() request. At the same time, having the
last updated
timestamp would be helpful for knowing if we need to force-purge the caches
because the image has been updated. I'm leaning towards the former, as
I'd rather
make action=purge force a recache.
2) Thumbs are still generated by the remote wiki. While I don't like
idea of the server
load being put on them, Brion reminded me that local wikis might not be able to
transform the same mediatypes the remote wiki can, so getting the
thumb from there
is probably safer.
Thanks for any input people can give :-)
-Chad
On Thu, Jul 3, 2008 at 9:00 AM, <demon(a)svn.wikimedia.org> wrote:
> Log Message:
> -----------
> Bug 14088 - excessively long block expiry times no longer bork the logpage. Reject if over 50 chars.
> . . .
> - if (strlen($expirestr) == 0) {
> + if ((strlen($expirestr) == 0) || (strlen($expirestr) > 50)) {
> return array('ipb_expiry_invalid');
* You should use a named constant instead of the magic number 50.
* The contents of 'ipb_expiry_invalid' should clarify that block
expiry times can't be longer than 50 chars.
* Shouldn't this be using mb_strlen or some equivalent, not strlen?
* Are you really sure that no default block time, in any language, on
any wiki, will ever be more than 50 characters long? It would be best
to only do this check if it's a custom duration. (As far as I'm
reading it, this is not currently the case.)
On Thu, Jul 3, 2008 at 9:00 AM, Anthony <wikimail(a)inbox.org> wrote:
> On Wed, Jul 2, 2008 at 6:59 PM, Marcus Buck <me(a)marcusbuck.org> wrote:
>> A central repository for templates and other
>> stuff which is useful on many projects could solve the problems for
>> Wikimedia projects. But not for other MediaWiki projects
>
> Why not? InstantCommons was recently enabled:
> http://intelligentdesigns.net/blog/?p=91
>
> It's working great. No more copying images from one wiki to another
> as long as the image is in commons. I wish I could get *that* for the
> infobox templates, {{fact}}, etc.
>
> A central repository for templates would probably be *primarily*
> useful for third party MediaWiki projects, because of the language
> issues. To be useful across Wikimedia projects, localization issues
> would greatly complicate the implementation. For that reason, maybe
> Commons isn't really the right place for it...
>
> I'll look into $wgEnableScaryTranscluding. The name scares me, though...
>
> _______________________________________________
> foundation-l mailing list
> foundation-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>
InstantCommons is _not_ live. The code itself says it's very hacky
and inefficient and should only be used for testing. Additionally,
with no local caching (I implemented some preliminary description-page
caching last night, still in development though), it'll just add to the
WMF server load on _every_ pageview of your local wiki.
Please do not encourage people to use this yet...
-Chad
On Wed, Jul 2, 2008 at 10:16 AM, Gerard Meijssen
<gerard.meijssen(a)gmail.com> wrote:
> That is not here and now. At this moment we are considering the
> implementation of the Babel extension, we are not considering something we
> did not do.
An essential part of evaluating any proposal is evaluating whether the
basic idea of the proposal is flawed in some important way. If flawed
solutions are adopted just because people have already put the work
into them, more and more work will be put into them over time,
papering over their flaws without really addressing them. Similar
specific solutions will be adopted for similar problems, requiring yet
more work. The end result will require more work and be less useful
than if the original work had been scrapped for its flaws to begin
with.
For an example, consider user rights changes. When developers stopped
changing ranks and that privilege was divested onto stewards and
bureaucrats, stewards got Special:UserRights and bureaucrats got
Special:MakeSysop. MakeSysop was a narrow and inflexible solution: it
was an entire extension, an entire different interface and code base,
to do a subset of what UserRights could do. When the desire for more
flexibility arose, like the ability to assign bot rights,
Special:MakeBot was written. Every time more flexibility was
required, it couldn't be provided; it simply couldn't be added without
writing and reviewing a whole new extension. Proposals for rollback
groups and all sorts of other things simply died because there was no
way to implement them.
Only years later did some developers (in fact, me, and Werdna) decide
a more flexible system would be useful. This obsoleted all the work
that had gone into MakeSysop, MakeBot, GiveRollback, and so on, and
probably took less work than went into them to begin with. It opened
up many new options and was overall a greatly superior solution. If
people had said, from the beginning, "Wait, why are we writing an
extension that only gives sysop/bureaucrat when we could put in the
extra effort to make it properly flexible?", many developer-hours
would have been saved, and communities would have gotten the ability
to configure their rights much more flexibly years earlier than they
did.
When a solution is presented that's too narrow, it should be rejected,
regardless of how well it achieves its task. Accepting a flawed
solution because it sort of works well enough is a recipe for wasting
a huge amount of time and effort down the road. Do it once and do it
*right*. The ability to localize and import templates from some
common location (Commons may make the most sense, not Meta) would be
vastly more valuable and more straightforward than this as well. We
shouldn't compromise for such a greatly inferior solution. "Works
well enough" is not acceptable in any software project with standards.
On Wed, Jul 2, 2008 at 10:27 AM, Ilmari Karonen <nospam(a)vyznev.net> wrote:
> "Perfect is the greatest enemy of the good enough." I still haven't
> looked at the specific extension being proposed, but, assuming it
> doesn't somehow irreversibly drive us down a dead end, we can always
> start with what we have and improve it later.
Except that people won't, if what they have isn't completely broken.
The absence of functionality is the best drive for improvement. It's
all too easy to get some basic functionality up and then lose interest
in revamping it so it really works right, when the path of least
resistance is to build incrementally on the flawed base that's already
present.
On Wed, Jul 2, 2008 at 10:47 AM, Andrew Whitworth <wknight8111(a)gmail.com> wrote:
> The idea of having a generalized extension for sharing pre-made and
> pre-localized templates across projects is an interesting one.
> However, with the exception of these babel templates (and maybe
> copyright licensing templates), I can't imagine too many templates
> that are going to be useful across both projects and languages. A more
> general solution is only desirable if there is a more general class of
> problems to solve. The idea that it might be nice to be able to share
> more templates then just Babel is a good one, but the reality is that
> there are few other templates which could possibly benefit from this.
I think you'll find that when a flexible new feature becomes
available, people will find a lot of unexpected uses for it. Some
random thoughts:
* People could transclude their user page from Commons to all wikis
they have accounts at. (Okay, this is better served by a global user
page.)
* Userboxes other than Babel could be centralized.
* Copyright templates. Copyright policy is typically pretty uniform
across projects of the same language, and at a minimum, things like
"this work is in the public domain because it was published in the
United States before 1923" should be more or less universal. (Well,
except in non-US countries that don't recognize the rule of the
shorter term, but you see the point.)
* Help pages could be transcluded instead of being manually copied as
they are now.
* Miscellaneous helper templates like {{!}}, {{-}}, {{infobox}}, etc.
* And, of course, Babel!
There are probably quite a few other things I couldn't immediately think of.
On Wed, Jul 2, 2008 at 11:39 AM, Gerard Meijssen
<gerard.meijssen(a)gmail.com> wrote:
> This discussion is about ... I do not know... There is a Babel extension it
> works, it is even configurable.. I made the mistake to ask for comments for
> the last time. It is only now that people wake up to the existence of this
> functionality and start asking questions that would be appropriate before
> the functionality was finished.
Did you actually ask for comments before the functionality was
finished? I remember noticing all the commits to Babel and thinking
"Hey, I wonder what that new extension is that all these people are
working on." I read every post on Wikitech-l and I'm pretty sure I
would have remembered had anything been posted there at or around that
time about the proposal.
On Wed, Jul 2, 2008 at 4:29 PM, Andrew Whitworth <wknight8111(a)gmail.com> wrote:
> I would disagree with this assertion about optimality. In addition to
> standardizing the templates, they will be able to use ISO language
> codes automatically and update translation text from betawiki. For the
> problem that this is trying to solve, a simplification to the forrest
> of babel templates, increase in interlingual participation, and
> further integration of betawiki translation efforts into this, I would
> say the extension is a highly optimal solution.
MakeSysop was a pretty well optimal solution to the problem that it
was trying to solve, too. The issue was that it was trying to solve
the wrong problem. The same applies here. For all I know, Babel is a
flawless fix for what it tries to do, but I don't care, because it's
trying to do the wrong thing.
If updating from BetaWiki is so important, that could be part of a
transclusion-based solution. Such functionality would be useful for
more than just Babel templates. In practice I don't know why it would
be such an advantage over editing the stuff on Commons or Meta or
wherever.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
tstarling(a)svn.wikimedia.org wrote:
> Revision: 36783
> Author: tstarling
> Date: 2008-06-29 20:02:42 +0000 (Sun, 29 Jun 2008)
>
> Log Message:
> -----------
> Remove hack for old APC bug that's fixed now. Was causing problems
> for
> DumpHTML (and probably other command line scripts) because $IP was not
> the same as dirname(__FILE__), causing double-inclusion.
Does this mean it's safe to remove the .deps.php files for language &
skin classes as well?
- -- brion
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkhr8soACgkQwRnhpk1wk467XgCgzTki7iz8PMaaKP+pMcPICOsz
UWQAnjLrKa9g/h/PaEThzgM78APTN2Mo
=UAov
-----END PGP SIGNATURE-----
This option was making sense when blocking registered users was an
experimental feature, but currently it's set to true everywhere and
hardly there's any third-party wiki that actually use it. So, does it
make sense to remove this option completely?
--
Max Semenik ([[User:MaxSem]])
> From: midom(a)svn.wikimedia.org <midom(a)svn.wikimedia.org>
> Date: Jul 1, 2008 9:55 PM
> Subject: [MediaWiki-CVS] SVN: [36856] trunk/phase3
> To: mediawiki-cvs(a)lists.wikimedia.org
>
>
> Revision: 36856
> Author: midom
> Date: 2008-07-01 19:55:17 +0000 (Tue, 01 Jul 2008)
>
> Log Message:
> -----------
> new feature! a blank special page! (thanks to everyone, who made
> Special:Version heavy :)
>
[...]
> +# Special:Blank
> +'blankpage' => 'Blank page',
> +'intentionallyblankpage' => 'This page is intentionally left blank',
> );
>
Does anybody know whether the proper expression is "This page is
intentionally left blank" or "This page intentionally left blank"
without the verb? I think I have seen the latter version more often in
manuals.
Bryan
On Wed, Jul 2, 2008 at 1:30 AM, Gerard Meijssen
<gerard.meijssen(a)gmail.com> wrote:
> The number and the
> distribution of localisations of the extension is better ensured by having
> an extension.
Possibly, yes, but I don't think such a special-purpose extension is
the right way to do this. There are really only three benefits I see
here:
1) Extensions can use Betawiki for localization.
2) Extensions can be easily installed and maintained on all Wikimedia
projects at once.
3) Extensions can be easily installed by third parties.
Now, these are real benefits. But there's no reason to restrict them
only to Babel. What if you achieved the following instead:
1) Collections of templates can use Betawiki for localization.
2) Collections of templates can be easily installed and maintained on
all Wikimedia projects at once.
3) Collections of templates can be easily installed by third parties.
This would have been as easy to do as writing the Babel extension, I
suspect, and a lot more useful.
> One of the reasons for the extension is NOT to have to maintain a long list
> of templates. Templates are nice for local usage. When they are to be used
> on all our wikis they are a pest. When they are also to be used by projects
> outside of the WMF they are clearly inferior.
>
> Templates that are to be used on multiple projects suck big time.
And this is the problem that should have been addressed to begin with.
You should not write software to solve a narrow problem when you
could solve a much bigger problem just as easily.
Thanks to SUL, I now have accounts on several wikipedias for "drive-by
edits", wikipedias I don't frequent often. I've already been greeted
in several of them, in the local language of course. This is all nice,
but I thought it might be more helpful for both myself and users on
that local wiki if there were some automatic indicator about my usual
hunting grounds. Like, "contact this user on en.wikipedia,
de.wikipedia, commons.wikimedia" (with links to my talk pages there).
That way,
* I don't have to add babel boxes / language links to each and every
user account SUL generates for me
* I don't have to frequent a few dozen talk pages
* People can choose a language to talk to me, on a page I actually frequent
Alternatively, it would be nice to declare one page my "unified talk
page", and transclude that to every wiki. But that has "giant mess"
written all over it...
Magnus
I wrote an extension for PHP to produce a custom HTML error message when
PHP encounters a fatal error. It's now live on Wikimedia. Previously,
fatal errors were generally displayed to the user as blank pages.
The HTML is based on the squid error message. It can be updated by editing
this file:
<http://svn.wikimedia.org/viewvc/mediawiki/trunk/php/wmerrors/error.html>
and then copying it to /home/wikipedia/common/php-fatal-error.html and
syncing it. There is no need to restart Apache.
The extension at present is only a slight improvement over PHP's
error_prepend_string/error_append_string, but there's plenty of room for
improvement.
-- Tim Starling