On Tue, Jul 1, 2008 at 5:51 PM, Brion Vibber brion@wikimedia.org wrote:

That is of course ridiculous, only a couple of templates should be required for "box with a number in it".

Remarkably, at least some of them appear to be manually-typed-out HTML, or substed or something. Apparently people didn't believe in meta-templates?

http://en.wikipedia.org/w/index.php?title=Template:User_ksh&action=edit http://en.wikipedia.org/w/index.php?title=Template:User_zh&action=edit

Some use a template . . .

http://en.wikipedia.org/w/index.php?title=Template:User_de&action=edit

. . . but it's {{userbox}}. Evidently something like

{{babel|de|German language|Dieser Benutzer spricht '''[[:Category:User de|Deutsch]]''' als '''[[:Category:User de-N|Muttersprache]]'''.}}

didn't seem useful to anyone.

To be fair, though, you really do have to have one template for each language/proficiency combination, if you want the sentence saying "This user speaks Old Church Slavonic on a native level" or whatever properly translated to each and every one of the hundreds of languages that at least one person speaks. Whether this is grounds for an extension, rather than a bunch of master templates on Meta that get copied out to the projects regularly by friendly neighborhood bots, is a separate question. (Now, if the extension were one to enable scary transclusion in a sane fashion . . .)

Brion Vibber brion@wikimedia.org wrote:

That is of course ridiculous, only a couple of templates should be required for "box with a number in it".

On MetaWiki we implemented an overhauled user language template system, which only uses one meta-template with subpage localizations (see http://meta.wikimedia.org/wiki/Template:User_language). It includes a well-defined set of levels (unlike the old babel system), uses only one sorted category per language, and has various other improvements made possible with ParserFunctions. The babel system was phased out on MetaWiki long ago; see http://meta.wikimedia.org/wiki/Template_talk:User_language#Comparison_with_babel_templates.

Unfortunately, the proposed extension simply copies over the old en-Wikipedia babel system with its poorly defined levels, and includes a vague fifth level which is sometimes used on en-Wikipedia but virtually unused elsewhere<3>. If I recall correctly, GerardM or the authors said they had no interest whatsoever in merging the systems (like using the level explanations).

On Tue, Jul 1, 2008 at 7:04 PM, Simetrical Simetrical+wikilist@gmail.com wrote:

On Tue, Jul 1, 2008 at 6:42 PM, Jesse Plamondon-Willard pathoschild@gmail.com wrote:

...

On MetaWiki we implemented an overhauled user language template system, which only uses one meta-template with subpage localizations (see http://meta.wikimedia.org/wiki/Template:User_language). It includes a well-defined set of levels (unlike the old babel system), uses only one sorted category per language, and has various other improvements made possible with ParserFunctions. The babel system was phased out on MetaWiki long ago; see http://meta.wikimedia.org/wiki/Template_talk:User_language#Comparison_with_babel_templates.

Now that looks like *exactly* how this system should work. Good job to Meta. There's definitely no need for an extension here that anyone's pointed out.

---

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

I'm with Simetrical on this one. A well-designed template like the one on meta seems to work just fine, and the other wikis should copy their example, imo.

-Chad

Hoi, The system may work fine on Meta... That is fine for Meta. I am interested in seeing it work on other wikis where it does not work. The number and the distribution of localisations of the extension is better ensured by having an extension. When the meta functionality was developed, it was not well possible to talk about its "functionality" it was deemed to be neccessary to have only a predetermined set of values that were specified for Meta. At a later stage this list was reluctantly extended. At the time when both functionalities were developed, there was no wish to cooperate. I have kept Pathoschild informed about the extension developments ...

In the end the extension is clearly superior because:

- it does not need to be maintained by copying templates from one project to the other - it will not fall foul on the localisation of the parser extensions - the localisation is part of the Betawiki localisation and it has more localisations - the notion that the qualification of the levels are "inferior" is debatable

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.

Thanks, GerardM

On Wed, Jul 2, 2008 at 3:17 AM, mike.lifeguard mike.lifeguard@gmail.com wrote:

I agree; Meta's system works just fine as-is, and I see no need whatsoever to enable an extension which provides inferior functionality.

Mike

-----Original Message----- From: Simetrical [mailto:Simetrical+wikilist@gmail.comSimetrical%2Bwikilist@gmail.com ] Sent: July 1, 2008 8:05 PM To: Wikimedia Foundation Mailing List Cc: Wikimedia developers; wikipedia-l@lists.wikimedia.org Subject: Re: [Foundation-l] [Wikitech-l] Implementing the Babel extension

On Tue, Jul 1, 2008 at 6:42 PM, Jesse Plamondon-Willard pathoschild@gmail.com wrote:

...

On MetaWiki we implemented an overhauled user language template system, which only uses one meta-template with subpage localizations (see http://meta.wikimedia.org/wiki/Template:User_language). It includes a well-defined set of levels (unlike the old babel system), uses only one sorted category per language, and has various other improvements made possible with ParserFunctions. The babel system was phased out on MetaWiki long ago; see

< http://meta.wikimedia.org/wiki/Template_talk:User_language#Comparison_with_ babel_templates>.

Now that looks like *exactly* how this system should work. Good job to Meta. There's definitely no need for an extension here that anyone's pointed out.

---

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

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

On Wed, Jul 2, 2008 at 10:16 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:

Hoi, 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.

When you think that it is easy to localise templates, think again. There are many hard issues that have to be solved in this way. To name a few:

• Localising templates means fixating them in a specific way
• Templates are used in languages and many scripts. The text can be in

two directions.

• Templates are used for "info boxes", why not have the content localised

as well

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.

Gerard makes the good point that it's a lot of work to localize a template into 100+ languages, and there are few benefits for doing this to most templates.

--Andrew Whitworth.

Trying to understand this debate, I looked again at my user page at Meta: http://meta.wikimedia.org/wiki/User:Ziko-W A difference to my user pages at de.WP is that there is no level 4 at Meta, did I get that right? Another difference: at Meta there are only categories for User de, User eo and so on, but not for the levels (de-M, eo-4...). Is this the point we are talking about?

Ziko

On Wed, Jul 2, 2008 at 11:39 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:

Ziko, 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.

The Babel extension allows you to indicate on a wiki level what levels are available... It allows you to specify how you want your categories... It is based on current practices... The software is so clever that it allows for both the ISO-39-1 and the ISO-639-3 (or two character codes or three character codes..)

But I will be darned when i understand what the discussion is really about ....

Thanks, GerardM

Maybe if you had asked for comments _before_ implementing a decision, rather than after, you might've gotten better results. As it stands, some people have objections to your idea, and your only response is "you should've raised those before I asked for final comments."

You asked for comments, you didn't specify they all had to be supportive.

-Chad

On Wed, Jul 2, 2008 at 11:05 AM, mike.lifeguard mike.lifeguard@gmail.com wrote:

I don't see how "there are few other templates which could possibly benefit from this" - isn't that a major issue with license/warning/information templates and help pages? Indeed, this is a key complaint from third-party reusers. "Where are the welcome templates? Why isn't there any help documentation in the wiki?..." As well, for those working cross-wiki, learning the set of local templates is next to impossible - a standardized set of translated warnings and informational templates would be golden.

But those templates you name aren't standard, they are radically different on different projects. Think about the differences in warning users between en.wp, en.wb, en.wv, etc. Think about the different information that must be conveyed to new users on each project with {{welcome}}. There is no way to standardize this information in any meaningful way, without asking all our projects to just be more like wikipedia.

Now, I won't disparage the idea that standardized user-welcome and user-warning templates would be nice for under-populated small wikis, and I'm sure the SWMT would love these. However, there are going to be a lot of exceptions for larger and more-established wikis that do not want to share message templates with meta/en.wikipedia.

In contrast to these special exceptions (which could easily be implemented in a separate extension), the babel templates are universal and do not need to make "special exceptions".

There is a fairly easy solution if we want to have a consistent set of babel templates across all wikis: Special:Export on the templates at meta, Special:Import on each wiki, and create the appropriate categories. Granted, there are >700 wikis, but this can be scripted. I would argue that babel templates, license templates, certain warning templates and a good set of help pages should all be translated and synced in this way.

This whole idea seems so unfeasible in comparison to the proposed extension. Basically, you're saying it would be easier to: 1) Write a script to perform the necessary exports and import them to

700 wikis *(for varying technical definitions of the word "export"

and "import") 2) Run said script at least once, plus additional times to account for new languages that need to be added later 3) Use the same script, or a new version of it, to update template translations on all 700 wikis, if the text of a template is updated, retranslated, improved, or otherwise modified.

If the problem is sharing templates cross-wiki, then this is not the solution. People like the SWMT may have needs which are sufficiently specialized that they should have customized extensions or technical solutions (and I support this 100%, the SWMT should be given anything they ask for). The babel templates problem is separate and distinct, however, and should not be lumped into the same solution as all our other needs and desires.

--Andrew Whitworth

--Andrew Whitworth

On Wed, Jul 2, 2008 at 2:50 PM, mike.lifeguard mike.lifeguard@gmail.com wrote:

Exactly! And the babel templates are exactly the same. /If/ we decide to have a system standardized across wikis (a good idea, IMO) then hardcoding them is not an optimal solution.

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.

The optimal solution is something like:

• https://bugzilla.wikimedia.org/show_bug.cgi?id=4547

I do like this idea, in theory. What I don't like is, as I said before, that we would want to provide exceptions for wikis that don't want to be using the shared templates. However, if this was implemented in a similar manner to how image sharing is, that a local copy is taken if it exists and the version from commons is taken otherwise, that would be fine by me. You still lose some of the features of the babel extension, however, but you do solve the core problem.

--Andrew Whitworth

On Thu, Jul 3, 2008 at 7:21 AM, Chad innocentkiller@gmail.com wrote:

FWIW: Has anyone even asked the smaller wikis if they _want_ to use standardized Babel templates (or any community, for that matter?).

I have just recently started working on a smaller project, Latin Wikisource, and (surprise surprise) there were no Babel templates. This project was started in November 2003. A new user asked what was going on:

http://la.wikisource.org/wiki/Vicifons:Scriptorium#Babel

Usually my first edit on a non-English wiki is to add a Babel box to inform the local community that I can only easily read English. I often find that the templates don't exist.

ar.ws : no {{Babel}}; {{User en}} works, but {{User ar-0}} doesnt. az.ws: no {{Babel}}, {{User en}} works, but {{User az-0}} doesnt. bg.ws: no {{Babel}}, {{User en}} or {{User bg-0}} cs.ws : an admin told me they dont have user boxes, so I removed them from my user page out of respect. http://cs.wikisource.org/wiki/U%C5%BEivatel_diskuse:Jayvdb da.ws: no {{Babel}}, {{User en}} or {{User da-0}} de.ws: {{Babel|en|de-0}} works el.ws : {{Babel|en|el-0}} works es.ws : no {{Babel}}; {{User es-0}} works, but {{User en}} does not et.ws : no {{Babel}}, {{User en}} or {{User et-0}} fa.ws : no {{Babel}}; {{User fa-0}} works, but {{User en}} does not fi.ws : no {{Babel}}, {{User en}} or {{User fi-0}} fo.ws : no {{Babel}}, {{User en}} or {{User fo-0}} fr.ws : no {{Babel}}; {{User fr-0}} works, but {{User en}} does not he.ws : {{Babel|en|he-0}} works hu.ws : no {{Babel}}; but {{User en}} and {{User hu-0}} both work ja.ws : no {{Babel}}, {{User en}} or {{User ja-0}} kn.ws : no {{Babel}}, {{User en}} or {{User kn-0}} lt.ws : {{Babel}} exists, but neither {{User en}} or {{User lt-0}} do. mk.ws : no {{Babel}}, {{User en}} or {{User mk-0}} nl.ws : {{babel|en|nl-0}} works pl.ws : {{babel|en|pl-0}} works pt.ws : {{babel|en|pt-0}} works ro.ws : no {{Babel}}, {{User en}} or {{User ro-0}}

French Wikisource was a surprise - they are one of the largest Wikisource projects.

Anyway the point is that smaller wikis usually don't have a proper Babel system, and this is a stumbling block for collaboration.

For all we know, the various wikis _like_ their babel templates and don't want some extension deciding things for them. I'm all for interwiki cooperation, but let's ensure it's actually cooperation and not the Meta/Foundation-l community deciding something for the rest of the projects.

The Babel extension provides new functionality, and does not override local setup. Each wiki will have the option of adopting the new functionality.

I think a Babel extension to manage and standardise these templates is a suitable solution to an actual problem. Meta templates are fine, however this is only a viable solution if other projects can inherit templates from meta or another wiki dedicated for that task (such as BetaWiki). One concern with the {{user language}} approach on meta is that it is not backwards compatible with {{Babel}}.

Looking forward (to address the concerns that this extension is short sighted), the Babel extension could be extended to include other very common strings that have, over time, proven to be a useful UI element that needs to be internationalised in order to assist users who work on wikis that are in a language that the user does not understand.

-- John

On Wed, Jul 2, 2008 at 11:05 AM, mike.lifeguard mike.lifeguard@gmail.com wrote:

There is a fairly easy solution if we want to have a consistent set of babel templates across all wikis: Special:Export on the templates at meta, Special:Import on each wiki, and create the appropriate categories. Granted, there are >700 wikis, but this can be scripted.

One complication to this is that templates often include other templates. I've found it quite time consuming transferring templates like the userbox templates to my own wiki. A script *could* be made to automate this, but it'd be non-trivial to create.

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@lists.wikimedia.org [mailto:foundation-l-bounces@lists.wikimedia.org] On Behalf Of Simetrical Sent: 03 July 2008 00:24 To: Wikimedia Foundation Mailing List; Wikimedia developers; wikipedia-l@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@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@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@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@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@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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Simetrical schrieb:

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

Simetrical, I agree with you, that it would be very useful to create a general solution to transclude content from a central repository (as I said in my earlier post on this list). But still, I think, the Babel extension has much value. 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. As an example, let me point to the OpenStreetMaps (a project, by the way, which has much potential for cooperation with Wikimedia, Wikipedia and our other projects really are lacking a good map utility) wiki. They have a wiki for coordination of their work on their map engine. This wiki is multilingual and people with many different native languages are working on it. A Babel system for marking the users language skills would be useful for them like it would be for any other multilingual wiki. But they really have no use for copyright templates or other stuff, cause there are no other wikis they could share with. The whole OpenStreetMaps project has only one wiki.

So the extension would be useful for many non-Wikimedia multilingual wikis, which are not members of wiki families. I guess there are many wikis like that out there. So the extension _is_ useful like it is.

For Wikimedia the problem "Babel" can be solved with the extension _or_ with the central repository. The central repository is useful for Wikimedia and should be implemented. But if Babel exists (cause it is useful for many non-Wikimedia projects), why maintain two separate Babel systems? Do both. Central repository and extension.

Marcus Buck

Hoi, Without localisation there is not much point to it. Thanks, Gerardm

On Thu, Jul 3, 2008 at 3:00 PM, Anthony wikimail@inbox.org wrote:

On Wed, Jul 2, 2008 at 6:59 PM, Marcus Buck me@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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

On Thu, Jul 3, 2008 at 9:00 AM, Anthony wikimail@inbox.org wrote:

On Wed, Jul 2, 2008 at 6:59 PM, Marcus Buck me@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@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 Thu, Jul 3, 2008 at 8:24 AM, Simetrical Simetrical+wikilist@gmail.com wrote:

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

You are stating that the wasted hours put into MakeSysop, MakeBot, GiveRollback etc. could have been better spent building UserRights, but that is not how open source works. It is rare for the right solution to be the first incarnation. Each of those extensions was simple and met the need at the time. The need to build the right solution only came apparent because those extensions provided a good working model for determining which additional level of indirection was necessary when building the UserRights extension. The right solution only came years afterward, and if the wrong solution had not existed in the interim, who knows, wiki's might never had taken off.

http://c2.com/cgi/wiki?TheBestIsTheEnemyOfTheGood

-- John