Hoi, If there was only a number in it... There is however a text in the templates in the language that is indicated, the text is RTL or LTR where applicable. Anyway, I agree with you that such a high number of templates is not really what we want. and consequently the Babel extension provides a really welcome relief. Thanks. GerardM On Tue, Jul 1, 2008 at 11:51 PM, Brion Vibber <brion(a)wikimedia.org> wrote:

Simetrical wrote: The Babel templates are the _original_ userboxes. The others, like "This user likes strawberry ice cream", came around later when people started creating their own parodies and imitations of the Babel boxes. They also date from around the time when [[Wikipedia:Avoid using meta-templates]] was written, and from long before it was rebutted by [[Wikipedia:Don't worry about performance]]. Which, mind you, was also before ParserFunctions and a number of general improvements to the parser, so the concern wasn't _quite_ as silly then as it may seem now. Actually, the reasonable thing would be to turn these templates into interface messages, probably specified via a simple extension, so that they can automatically be made available on all projects without having to create local copies on each wiki. Which is more or less what I assume (without actually looking, mind you) the proposed extension is doing, perhaps with some syntactic sugar thrown on top of it. -- Ilmari Karonen

On Tue, Jul 1, 2008 at 5:51 PM, Brion Vibber &lt;brion(a)wikimedia.org&gt; wrote: We try to use very few with our system on Meta-Wiki. <http://meta.wikimedia.org/wiki/Template:User_language> One of my main problems with the babel extension is that I don't think it gets rid of the *huge* number of categories that need to be created (otherwise you have ugly redlinks). The system on Meta-Wiki greatly reduces the number of categories, but I've been told that the extension's developer was completely against any changes to the extension (I didn't hear it directly from him). -- Casey Brown Cbrown1023 --- Note: This e-mail address is used for mailing lists. Personal emails sent to this address will probably get lost.

On Wed, Jul 2, 2008 at 2:36 AM, Niklas Laxström &lt;niklas.laxstrom(a)gmail.com&gt; wrote: You still aren't understanding me... I'm *love* the idea of an extension to do this, I would rather we install it/one with the best features first (especially if it's Wikimedia-wide). $wgBabelUseMainCategories A boolean (true or false) indicating whether main categories featuring all users who specify a level for that language should be added to a xx category; defaults to true. How are they added to the category? Ordered by ability, then alphabetically... or just alphabetically? Please check *your* fact first. :-) I am *for* the extension, I just wish it were tweaked to be more efficient. I'm surprised no one is yelling "enwiki-centric" because the levels were in-fact based off of enwiki... Furthermore, I put the information in parenthesis *so* he wouldn't be offended, I have no reason to believe that what I told was incorrect considering I heard it from a pretty reputable source. -- Casey Brown Cbrown1023 --- Note: This e-mail address is used for mailing lists. Personal emails sent to this address will probably get lost.

Casey Brown 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. Well, installing a global extension obviously forces global standardization of the levels. There's two relatively obvious ways to go about that: either pick the largest common subset (which would essentially be the 0/1/2/3/native system from Commons) or the smallest common superset (which would more or less be the 0/1/2/3/4/native/5/... system from enwiki) of the various systems currently in use. The choice comes essentially down to which one you'd rather deal with: a bunch of vaguely defined and overlapping crufty "vanity" levels cluttering up the system, or bazillion enwiki users screaming bloody murder because you're taking away their "expert level" babel box. Of course, it occurs to me that it might be possible to have it both ways: set up the global system with only the few globally used levels, and let individual projects maintain any additional levels they want using either local additions to the extension or simply the existing template-based mechanism. (However, as issue worth considering is that, if we allow local additions to the babel extension, some people *will* want to migrate *all* their userboxes to it.) -- Ilmari Karonen

On Thu, Jul 3, 2008 at 8:38 AM, Siebrand Mazeland &lt;s.mazeland(a)xs4all.nl&gt; wrote: It's still scary and largely inefficient. While entries _can_ be cached locally, there's no way of automatically expiring the cache when the original copy is updated. Instead, it expires at a given time. See bug 9890. -Chad

Oh, it's still a proposal merely, but its something that I plan to build at some point in the future (it's needed for some of my other extensions and uses), but I do have plans to make a TransWiki extension. http://wiki-tools.com/wiki/TransWiki There are only two tricky points. I've already theorized on how to get stuff, how to ensure efficiency, and what not. The first issue is syntax. I've had a few thoughts, note that the first goal is to make this work with a tag, the second goal is making this work with a commons type setup. My first thought on the syntax was something like <transwiki name=anime page=Template:Stub /> with an optional namespace=# in case the other wiki and the module currently used for connecting to another wiki did not give out information on another wiki's custom namespaces. Though do note that in this syntax, XML like syntax is used to avoid conflicting with syntax other things use (and do remember that at a core the point here is NOT to look like template transclusion, it is to transclude WikiText from another wiki into a Template where you then include that template into a page), however because things are transcluded at the extreme beginning, it doesn't actually use MediaWiki's xml tag stuff, this is all just regex replaced before anything happens to it (Yes, that does mean that <transwiki /> is immune to <nowiki/> and will transclude even if wrapped in it... Of course, that could also be regarded as a feature ;) if you were to want to transclude something and then go and highlight what code was used; But all in all, a syntax that WON'T be used in any other case is extremely necessary for this because of that core reason that the tag will not be affected by <nowiki/>) As for the commons like setup, by default I don't want to transclude /everything/. I will consider a config option for that purpose. However, the plan is first to use something like a __SHARED__ tag on a commons wiki, then pages tagged with that will be transcluded to all the inheriting wiki if the page there does not exist. (This also means that you could put __SHARED__ on your userpage and have it transcluded from commons even though it's not in the Template: namespace) The second issue is the parser. I've talked to Tim many a time before, but there are two bits in the parser (for two different extensions) which do NOT, exist in the parser right now, and I'm having a hard time finding a place to introduce a hook for that purpose. /(Feel free to ignore this first speal, it's not as relevant)/ The first one is to do with the preprocessor and WikiCode; I need to allow a #parserfunction to access the frame of the parent template (It's supposed to extract a list of template variables used inside of the template call it is inside of -- This could probably also be used for a #macrovar: type parserfunction where you grab the value of a variable not in the current scope, but in the scope of the template outside of the current template ;) as confusing as that is, it does have a useful purpose... Think, proxying a template with a shortened name, but only setting what you need to set, allowing a #macrovar: inside of that template to grab the variable from current scope and use it instead of directly passing the variable to the template [this allows for things to be expanded without breaking things and needing to edit every single proxy template which uses a simpler config]. But moreover, it could be used for something as simple as say {{empty|foo|default}} which works similarly to {{{foo|}}} except it works as if you inserted {{#if:{{{foo|}}}|{{{foo}}}|default}} into the page itself.) The second one, and more important in this case is to do with ParserBeforeStrip, and transclusions. Basically, because we are transcluding early (before anything is parsed at all) we need a hook or two which will allow us to insert WikiText at this point in loading. ParserBeforeStrip works nice for that purpose in the current page, it however does not work for transclusions which is the purpose of the TransWiki idea. I need to find a location in the parser where I can insert a hook to modify the text of a template being transluded (it also needs to give the Title::... instance for that template being transcluded, otherwise we won't be able to do this in a commons like way and will be limited only to tags). I however have had issues finding a place to put this kind of hook inside of the parser. ~Daniel Friesen(Dantman) of: -The Nadir-Point Group (http://nadir-point.com) --It's Wiki-Tools subgroup (http://wiki-tools.com) --Games-G.P.S. (http://ggps.org) -And Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) Angela wrote: