[Foundation-l] [Wikitech-l] Implementing the Babel extension

Wed Jul 2 22:44:46 UTC 2008

I have a great deal of sympathy for the position you are taking, but that is
mostly based on the 20+ years experience that says you're tilting at
windmills.

Brian McNeil

-----Original Message-----
From: foundation-l-bounces at lists.wikimedia.org
[mailto:foundation-l-bounces at lists.wikimedia.org] On Behalf Of Simetrical
Sent: 03 July 2008 00:24
To: Wikimedia Foundation Mailing List; Wikimedia developers;
wikipedia-l at lists.wikimedia.org
Subject: Re: [Foundation-l] [Wikitech-l] Implementing the Babel extension

On Wed, Jul 2, 2008 at 10:16 AM, Gerard Meijssen
<gerard.meijssen at 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 at 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 at 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 at 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 at 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.

_______________________________________________
foundation-l mailing list
foundation-l at lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l