On 11/06/05, Tomer Chachamu the.r3m0t@gmail.com wrote:

...

If you wanted to link that to the 1 E1 m, you would just do: ((([[100. yards]])))

Surely only two brackets are sufficient?

Are you suggesting something like [[100 yards]] to link and provide automatic unit conversion? I avoided this because of potential conflicts. For instance:

[[one foot]] contains twelve inches. [[one foot]] is the name of a snowboarding trick, according to Wikipedia.

That is why I suggest placing the [[ ]] inside of whatever syntax provides automatic unit conversion if the user wants the automatic link to the 1 E* m series of pages. Then, if they want the unit linked elsewhere, they can do [[link|(((3 ft)))]].

If instead you were suggesting only two parentheses instead of three, that is fine with me. As I state on the page, the entire syntax is up for debate. I saw the three parentheses suggested somewhere when I started work, so that is what I went with. Clearly the fewer characters typed, the better. I haven't been around Wikipedia long enough to know what I might be conflicting with by choosing something shorter.

Matt Wright

On 11/06/05 Ævar Arnfjörð Bjarmason avarab@gmail.com wrote:

Please make it an extension and not part of the core syntax.

Can you explain this a little further? The way it is currently written is similar to date formatting.

* Like DateFormatter.php, a UnitFormatter.php file now exists * Modifications in includes/User.php and includes/SpecialPreferences.php for preferences * Added lines simiar to DateFormatter in includes/Parser.php * Several new global arrays and functions were added to Language.php for cross-language operation $wgUnitSettingsEn = array(); $wgUnitNamesEn = array('1in' => 'inch', 'in' => 'inches', ...); $wgUnitAbbreviationsEn = array('in' => 'in', ...); $wgNumericPowerWords = array(..., '6' => 'million', ...); $wgNumericValueWords = array('0' => 'zero', '1' => 'one', ...);

getUnitName ( $unitcode ) {} getUnitAbbreviation ( $unitcode ) {} getWordsFromNumber( $number ) {} getNumberFromWords ( $words ) {}

Can this type of integration be done with an extension? If so, where would you suggest I read up on how to make it an extension instead of core syntax? This patch may be more useful for Wikipedia spceifically, rather than WikiMedia in general.

Matt Wright

On 11/06/05, Ævar Arnfjörð Bjarmason avarab@gmail.com wrote:

...

...

Please make it an extension and not part of the core syntax.

Can you explain this a little further? The way it is currently written is similar to date formatting.

Well I was thinking along the lines of an extesion like <unit>3 m</unit>

For how to do this, see: http://meta.wikimedia.org/wiki/Write_your_own_MediaWiki_extension

Ævar Arnfjörð Bjarmason wrote:

Please make it an extension and not part of the core syntax.

Please do not include it in MediaWiki at all.

This is my opinion. I defer to the judgment of others. But I think it is a perfectly awful idea.

--Jimbo

On 13/06/05, Lee Daniel Crocker lee@piclab.com wrote:

That's another one of my ulterior motives for cleaning up the extension syntax. The Mediawiki software is already suffering from some serious feature creep, and its use at other sites is only going to increase that pressure. I'm hoping that giving the feature-hungry masses a way to add some whizbang to the software that we at Wikipedia can choose to ignore may appease them a bit.

Well they can (and do [1]) do that, just as easily, with the existing extension syntax - your "<<extension foo bar>>" has a direct one-to-one mapping to the existing "<extension>foo bar</extension>" - or am I missing something?

Of course, there *are* limitations to that extension mechanism, but they're not to do with syntax; the ones that spring to mind are: * caching means mixing dynamic content into static pages is near-useless * there's no "clean" method of returning wikicode rather than HTML, or passing the results of the extension back to the parser (a simpler problem to fix, but no-one's got round to it) Between those two issues, a lot of the things people would like to do with extensions are a lot harder than they might seem.

BTW, there's also an "event hooks" extension mechanism, and an AuthPlugin system, so there's now quite a few ways for people to "add some whizbang"...

[1] http://meta.wikimedia.org/wiki/MediaWiki_extensions lists some of these.

On 6/13/05, Matt Wright mw@mattwright.com wrote:

I wrote the converter specifically for Wikipedia in response to a friend's suggestion that it would be nice and bug 235 in Bugzilla (which was clearly written as a proposal for Wikipedia based on Village Pump discussion).

First of all, it would be nice if you could attach the patch to bug 235 so people could try it out/comment on the implementation, whether it gets in the main tree or not.

making it an extension removes most of the functionality (user preferences, cache hashing, multiple language support, etc.).

Ideally extensions should be able to do anything, and theoretically can with the $wgHooks system, if there's anything you can't do please file a bug if there isn't one already.

It is clear that none of the top developers of the project like the idea, but I never really heard why. Is it because they think it can't be done well by software or that it complicates the syntax and adds load to the servers?

(Note: Although I happen to have CVS access the following is my opinion and not necessarily the one of the MediaWiki project, and certainly not that of Wikimedia)

First of all, if people dislike it they can dislike it for two reasons (that I can think of), I'll give you my view on both.

1. They don't want it in the main MediaWiki tree. 2. They don't want it on Wikimedia servers.

First of all MediaWiki is meant to be a general wiki distribution (see meta:Sites using MediaWiki), although its most noticeable deployment is on Wikimedia servers and indeed most development is something to scratch a Wikimedia-site based itch we still like to keep it reusable for other projects, the only people who seem to want this patch are the people on the English Wikipedia who want it because they can't agree on whether or not to use Imperial units or SI units so they agreed on using both, and since they don't want to maintain both versions manually or can't agree on whether to write "x km (y mi)" or "y mi (x km)" they want to have it done automatically.

So, the % of total installations where this would be used is a very small % of the total number of installations, very few people would presumably want to use it outside of Wikimedia and the only projects that seem to want it inside Wikimedia are projects written in English which are 4-10 but there are around 800 wikis (last I checked)

Furthermore your specific implementation is designed in such a way that people already maintaining the codebase would have more things to maintain, and people interested in rewriting the codebase (or the parser) would have more things to rewrite, it would touch the main wikisyntax (hence complicating it which is always a big sacrifice), preferences, parser cache, translation etc.

So, weighing in all the pros/cons of your implementation and the possibility of installing it on the Wikimedia cluster not to mention maintaining it indefinitely I think the cons vastly outweigh the pros.

Additionally, should one of the top developers note on bug 235 in Bugzilla that it has been discussed and is not desired, so that no one else wastes time on this?

I don't think that's a good idea, people mainly seem to have an issue with the idea of putting it in the main tree (your specific implementation) rather than something like a standalone extension.

Please do not include it in MediaWiki at all.

This is my opinion. I defer to the judgment of others. But I think it is a perfectly awful idea.

Your idea of MediaWiki may be different than mine but I see nothing wrong with including it in the extensions module and giving Matt CVS access to maintain it if people want to use it on their own wiki's (note that I don't have CVS admin access).

However I agree that something like this should not make it into the main syntax or the main distrubution for that matter.