Hi, On 05/05/2010 01:01 PM, Thomas Schmidt wrote:

Hi, going through the list of mediawiki extensions, I found some that might be useful for our new wiki, and that I would like to try out:

- http://www.mediawiki.org/wiki/Extension:VideoFlash allows us to embed videos from our youtube channel, and helps to move tube.o.o into the wiki

We're already moving tube into youtube/blip. No need to put it into the wiki. But as general possibility it sounds cool.

- http://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi gives us syntax highlighting for included example code snippets

Nice!

- http://blog.bemoko.com/2008/06/28/bugzilla-reports-for-mediawiki/ Can include some Bugzilla data into wiki pages

Looks nice but for what would we actually use it? I just skimmed over the usual suspect pages for bugzilla links and it seems to me that links are just fine. The only real benefit i see would be to integrate this into Template:Bug so one can use {{Bug|12345}} and gets the output but for most use cases this seems to be a bit much output. Did you have any specific use case in mind?

- http://www.mediawiki.org/wiki/Extension:QPoll http://www.mediawiki.org/wiki/Extension:SecurePoll Do we want to be able to do polls in the wiki?

No. We use connect/users for polls.

- http://www.mediawiki.org/wiki/Extension:Add_HTML_Meta_and_Title Can improve our pages for search engines

Sounds good.

- http://www.mediawiki.org/wiki/Extension:CategoryWatch You can add a complete category to your watchlist, that might be useful when we have people taking responsibility for a category, for example 'Applications'

Also cool.

- http://www.mediawiki.org/wiki/Extension:ShareThis Can notify social bookmarking sites about wiki pages

I don't know. Sounds unnecessary to me. I never ever wanted to report a wiki page and most of the social bookmarking pages have nice browser extension.

- FATE connect (to be written) Could include feature title, state and product by writing for example <fate>23567</fate> in the wiki markup or dynamically include search results for features.

Same as with the bugzilla extension i think. Henne -- Henne Vogelsang, openSUSE. Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org

Hello, on Mittwoch, 5. Mai 2010, Thomas Schmidt wrote:

Hi, going through the list of mediawiki extensions, I found some that might be useful for our new wiki, and that I would like to try out:

Sounds like I'll have to do another round of "comment on extensions"...

- http://www.mediawiki.org/wiki/Extension:VideoFlash allows us to embed videos from our youtube channel, and helps to move tube.o.o into the wiki

http://www.mediawiki.org/wiki/Extension:MediawikiPlayer could be an alternative and has a more recent release (2010-03-06 vs. 2008-08-20). (I'm using the MediawikiPlayer extension in a wiki I maintain.)

- http://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi gives us syntax highlighting for included example code snippets

Sounds good :-)

- http://blog.bemoko.com/2008/06/28/bugzilla-reports-for-mediawiki/ Can include some Bugzilla data into wiki pages

I think we had this on the list before ;-) This extension needs direct access to bugzilla's database, and I highly doubt the bugzilla team will allow this. If we want to include bugzilla data, we'll have to find (or write) something based on bugzilla's "official" interfaces, namely the RSS, XML or CSV export. The SimpleFeed extension might be a starting point. IMHO there would be one case where a connection to bugzilla would be useful: the {{Bug|123456}} could include the bug title and status, and even strikethrough automatically when the bug is fixed ;-) Note: If someone writes such an extension, caching the bugzilla data will rescue you from (otherwise) crying server admins ;-) (Just imagine how many bugzilla requests will be done from the "most annoying bugs" page... - showing results that are outdated since an hour is better than killing the server and then being killed by the admin.)

- http://www.mediawiki.org/wiki/Extension:QPoll http://www.mediawiki.org/wiki/Extension:SecurePoll Do we want to be able to do polls in the wiki?

IMHO no.

- http://www.mediawiki.org/wiki/Extension:Add_HTML_Meta_and_Title Can improve our pages for search engines

If used wrong, it can also cause the opposite effect ;-) - I prefer to "only" feed search engines with the content, not some metadata that may or may not have to do something with the page content. AFAIK the meta tags (especially keywords) are not really used by search engines anymore, because too many people abused them to spam search engines. BTW: the {{DISPLAYTITLE:foo}} magic word allows to change the <title> tag already. Besides that, the extension looks unmaintained. The infobox says "MediaWiki: 1.6.x, 1.8.x, 1.9.x or higher (not tested by author on most recent MW versions - i.e. > 1.12)" On the discussion page, there's a comment from August 2009 saying it doesn't work with PHP 5.3.0 without any response. (Needless to say that I don't recommend this extension, right?)

- http://www.mediawiki.org/wiki/Extension:CategoryWatch You can add a complete category to your watchlist, that might be useful when we have people taking responsibility for a category, for example 'Applications'

Sounds useful.

- http://www.mediawiki.org/wiki/Extension:ShareThis Can notify social bookmarking sites about wiki pages

IMHO as useful as a "print page" link that links to "javascript:document.print" - in other words: quite useless. As Henne already wrote, all social bookmarking sites provide their own browser plugin to submit a page - why should we duplicate this on the page? Fortunately it doesn't appear on all pages automatically (given that the sidebar is not enabled), and I hope not too many people add the <sharethis /> tag to a page ;-)

- FATE connect (to be written) Could include feature title, state and product by writing for example <fate>23567</fate> in the wiki markup or dynamically include search results for features.

Sounds like an interesting idea, but I wouldn't give it a high priority. (Maybe someone needs a project for next HackWeek?) I would only use it for showing details about a specific fate entry (similar to the to-be-written bugzilla extension, see above). Not sure if including search results would be useful - a simple link to the search on features.o.o does the same and saves the wiki server some load.

Do you think these extensions can help us, or did I miss an interesting one?

After having various funny problems with complex templates (before you ask: lots of ParserFunctions involved, and not in the openSUSE wiki), I installed ExpandTemplates. It adds a special page that shows the wikitext (not only HTML) a template generates. This can help when debugging templates. http://www.mediawiki.org/wiki/Extension:ExpandTemplates Another extension for maintenance is CrossNamespaceLinks. It adds a special page and lists pages (for example) in the main namespace that link to some user: page. http://www.mediawiki.org/wiki/Extension:CrossNamespaceLinks To encourage users to categorize articles, something like http://www.mediawiki.org/wiki/Extension:SelectCategoryTagCloud or http://www.mediawiki.org/wiki/Extension:SelectCategory could be useful. Both show a list of available categories when editing a page. I'm currently using SelectCategoryTagCloud, but found some problems: - it's impossible to set a root category per namespace, therefore it always offers all categories (even if the documentation says that this should work) - it has a tab which promises to show the category tree, but it only shows "coming soon" ;-) Because of the first problem, I'll test SelectCategory in the next days - I'll see if it has a different set of bugs... Oh, and I have another patch for MultiBoilerplate (not yet published) that enforces exact copies of the boilerplate (as in "don't process <noinclude> and <includeonly>") for some boilerplates - very useful for having a template for templates, not needed for article templates. The downside of this patch is that the boilerplate list currently needs to be specified in LocalSettings.php - not really doable for the openSUSE wiki. Changing it to read a Mediawiki:something page should be trivial though. The perfect solution would probably be to add an optional third column ("| raw") to the MediaWiki:multiboilerplate page, but I have no idea how much work this would be. Something Rajko proposed some time ago: Maybe the WikiEditor from http://www.mediawiki.org/wiki/Extension:UsabilityInitiative would be useful. Unfortunately it requires MediaWiki 1.16 (really, I already tried it with 1.15 without success). Regards, Christian Boltz --

Du testest hflacs ;-) Mit existieren Dateien testen (erwartetes Ergebnis: "geht") ist langweilig. Ich teste goldrichtig. Dazu hat der liebe Gott nämlich die User erschaffen. :-) [> Christian Boltz und Ratti in fontlinge-devel] -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org

On Wednesday 05 May 2010 06:01:41 Thomas Schmidt wrote:

Do you think these extensions can help us, or did I miss an interesting one?

UsabilityInitiative is set of extensions, but for us could be interesting WikiEditor . http://www.mediawiki.org/wiki/Extension:UsabilityInitiative Also there is WYSIWYG editor: http://www.mediawiki.org/wiki/Extension:FCKeditor_%28Official%29 It worked for me on simple texts, but it will fail with complicated structures. It can be turned on and off by the user, so it will not stand in the way for advanced editing. The most important application will be to edit tables. I mentioned few times ReaderFeedback : http://www.mediawiki.org/wiki/Extension:ReaderFeedback It can be nice complement to FlaggedRevs + Forums Q/A, as even non logged in users can give feedback without extra effort. Article that has low ratings can be checked on content quality. It is important that feedback is not simple few stars, so user has ability to tell what he likes. The only bad is that administrators will see 2 forms on the bottom, when logged in, but they are admins because they can handle that :) -- Regards Rajko, -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org