Talk:Wiki

This page is being considered for cleanup. Please discuss this page.

Discuss the Wiki here, including ideas for technical improvements to the wiki

Note: If you have ideas for the wiki, you can generally just do them, by editing the wiki! Big restructuring can be discussed in relation to WikiProject Cleanup, but in general we would encourage you to "be bold"

...but if you have ideas for technical improvements to the way the wiki works, e.g. extensions we should install, you might add them here, and/or raise tickets in trac. Trac tickets should probably be raised as 'component=admin' (dont have a seperate one for 'wiki' tickets).

---

multilingual ability

Option 1: Seperate namespaces

• Pro's : simpler back-end
• Cons  : Users have to put (eg) Francais: before french pages

Option 2: Seperate wiki's

• Pro's : *burp* its how Wikipedia does it?
• Con's more complicated back end, harder to upgrade

These namespaces need to be created properly which requires work by a sysop and someone with access to LocalSettings.php

There is now a Language links Template which uses the PageName.language format. --Dean Earley 11:32, 10 Jul 2006 (UTC)

Hi, this is a very interesting topic and it's nice that you already have a discussion here. I already posted about this topic on the german mailing list (Talk-de) and made a german posting on this wiki. Here is my opinion:

I think that the internatialialisation on this wiki (Option 1) is badly made. The reasons (Pro's for Option 2) are the following:

Pro 1 for Option 2: MediaWiki is using the ":"-prefix to put articles into namespaces. The delete template for example is in the template namespace, because the full name of the template is Template:Delete. When an user reads the De:Editing article he thinks that the article belongs to the "De" namespace. But it doesn's because you abuse the "De:" prefix for internationalization.

Pro 2 for Option 2: Some articles are not prefixed. The german Über article for example. But what happens when an other language wants to have an article with the same name? It's a naming conflict. One more example: Lower Saxony has a redirect to Niedersachsen... At the moment the Niedersachsen article is empty no one knows if it should be written in english or german.

Pro 3 for Option 2: MediaWiki has an build in and "out of the box" mechanism for internationalisation. It's called Interwiki-Links. (see Interwiki links to other languages and Wiki family)

That is why I suggest to realize Option 2... What do you think about this? When you decide to split this wiki into a wiki family I will volunteer to help with this. I have some experience with MediaWiki and would like to support this nice OpenStreetMap project (wiki).

--PMay 13:00, 20 June 2008 (UTC)

I think it's clear that option 2 is techincally more elgant solution for creating parallel wiki knowledgebases in multiple languages. The question is, are we embracing wiki translations to that extent? Would we translate so much of this wiki that it is worth the hassle of setting it up that way?

Option 1 is not fully explained here really. Dean is mentioning 'namespaces' but it doesn't require namespaces (in the MediaWiki sense of the word) just a page naming convention which introduces the space for diffent languages. This means it requires no configuration/installation whatsoever. That makes it very much the path of least resistance, hence that is the route we have ended up going down for translations of various key wiki pages (Main Page, About, OpenStreetMap License, etc) if only because the people who have FTP/shell access to the wiki server, are (quite rightly) not willing to dedicate a lot of their time to improving the finer details of how the wiki works.

But I'm not even sure if option 2 is better for our purposes. I think it's very important to offer all the basic OSM welcoming information in different languages, to attract worldwide contributors. We've done that by means of a page naming fudge. There's also no harm in people creating project pages for a specific location, in the local language, rather than english. Do we really want to take this to the next level and start developing the community in multiple separate languages? The OSM wiki is not the end-product here. It's just a communication channel. If we create more pages in more languages, maybe the wiki editing energy gets diluted. Maybe it might not be an improvement after all.

But then again this wiki community is getting bigger and bigger, so maybe we can start to think about this a little more. I'd be interested to know more about the improvements to MediaWiki which give you multilingual features out-of-the-box. Guess I should look into it.

-- Harry Wood 15:55, 23 June 2008 (UTC)

Here is how it works: You create a wiki family (I would choose Scenario 4: Multiple wikis sharing common resources) and then you just create interwiki links. I do not think that this interwiki link and wiki family technique works as a barrier between languages cause you can still set normal wiki links between the members of the wiki family. --PMay 18:52, 23 June 2008 (UTC)

Whether or not a wiki should be splitted into several wikis with different subdomains mainly depends on the purpose of the wiki content and on the grade of interconnectedness of the content in different languages.

For Wikipedia the content of a specific language forms a corpus of its own. The meta stuff, like discussions and policies, almost always is connected to a specific corpus. Therefore different subdomains are useful. (And additionally Wikipedia contains millions (and potentially hundreds of millions) articles, who would concur for page names in a single wiki.)

This wiki is different in purpose. It is a coordination wiki, which only supports the main work at the maps. Its not a content creation wiki like Wikipedia, but more into discussion and documentation of discussion result. Splitting the wiki into subdomains would hinder discussion and coordination.

In short: For Openstreetmaps we need one community with many languages, but subdomains would create many separate communities. (And subdomains do split up communities.)

Instead we should take measures to make the single wiki fitting better for hosting several languages. Whether pages are organized in language specific namespaces or in pseudo-namespaces is only an organizational question and not very important. Actually the volatility of wikis is the biggest problem. For example: I never read policy pages in other languages than in English, although English is not my native tongue and my English really could be better. But the problem is: the majority of translated pages are outdated. There are translators working on that, but they are never enough to keep all pages in synch. An important part of useful multilingual content is to keep the "central content" (in this case the English content) stable, with few changes. But stability and continuity of content is even harder to achieve in a splitted wiki. --::Slomox:: >< 01:53, 25 June 2008 (UTC)

How can I search a page specificly in one language? For example: I look for "tag", but only in German? Thanks, --Markus 18:57, 8 July 2008 (UTC)

You can't do that with this wiki because the langages are mixed. With the "wiki family" solution you could do this because you have one sub-wiki per language. --PMay 18:12, 11 July 2008 (UTC)

I was chatting the User:Firefishy about this problem at a recent mapping party. He's planning to add in language codes as wiki namespaces, which would allow you to search within a language, and filter 'recent changes' by language. To me this seems like a good solution. Might be a problem with talk page namespaces though. I think he's looking into it.-- Harry Wood 12:12, 11 September 2008 (UTC)

I think that option two is better because, even this wiki not being a final product, it has to be very well organized so less skilled users could easily learn and start participating in mapping activities. I think Wikipedia's model is much more organized, direct and clean than the namespace model.

I don't see discussion dispersion in this option because I think non-English wikis will tend to focus on mapping activities related to territories where their languages are spoken. I believe hard-users (even non-native speakers) will keep "wikiing" in English to discuss OSM tools, infra-structure, etc.

In most of in-development countries (like Brazil), English still a barrier, so having an structure where the user can choose his language from the very first step is awesome.

What do you think? We need open this discussion for voting?

-- Vitor George 12 September 2008

I clearly go for option 2. Started about 2 weeks ago reading lots of pages in english and german. My finding are:

• Navigation using german pages is awkward, because with each click you first will be on the english page with the need of an extra click to "german"
• Naming convention regarding page names is already out of sync. In some cases you will find <englishTerm> and <de:englishterm>, in others <englishTerm> and <de:germanTranslation of englishTerm>, in others <englishTerm> and <germanTranslation only, without de: in the beginning) - what is right? What about pages only existing as german page? Should they be names with de: , should they us the translated english term as page name?? (I don't think so, go for option 2 and use german names)
• What if I want to correct / add / change something on the german page - do I also have to correct it on the english page? Are "english" pages the master pages from which everything derives? I don't think so, because this would mean to get anything from other languages to the english page *and* back to all translated pages - would not work in a wiki, I guess. Therefore pages will develop into different directions (not being pure translations any longer - see Wikipedia). Good parts from other languages will survive and will be translated, while others parts will be unique in each language
• If there are important pages which must be provided in each language, using option 2 I would recommend to start with a copy of the english page (no translation) and add a statement in the beginning saying (in the right language): This page is currently only available in english. Feel free to translate the page into your language (if you can) and add whatever you think is needed...

I believe it is important also to care about the wiki. It will help attracting people to openstreetmap, if barrieres are as low as possible. Have a look in the forum, and you will find lots of topics which would better be covered by the wiki, because information can be structured much better. Drbobo 12:57, 11 December 2008 (UTC)

multilingual name spaces

I think you're seeing lots of potential for wiki growth. Enthusiasm is good. In practice though... well lets look at the Brazil example because I actually did a fair amount of work on the WikiProject Brazil page (and even some mapping in Brazil!), but there hasn't been that much activity on there wiki there. Only recently did somebody translate that page into Portuguese. Nobody has translated the About page into Portuguese yet (a page I consider to be very important as welcoming explanation)

So the Portuguese OSM community is probably fairly small, and then there's only a small percentage of those people concerning themselves with wiki edits. Now imagine this little bunch of people are thrust out into their own fresh wiki space. Yes they will be able to create pages with whatever names they like, but will they be better off for it? Possibly not, in fact the Portuguese language wiki would probably never develop much, and would rapidly descend into a spam riddled ghost town. With the current set-up our Brazilian contributors benefit from being part of the same wiki community. Basically the thing to remember is... this is not wikipedia. There aren't that many wiki editors.

Another complication with the wikipedia style option 2, is that you end up needing a shared 'commons' image repository for images (well I think you do anyway. Could be wrong about this) That's a big usability confusion, and no doubt quite a headache to set-up in the first place.

I guess another question is whether the translation should really have happened at [[Pt:WikiProject Brasil]]. Do we really want to attempt to translate pages about all the places? That's a question the namespace approach really doesn't answer either.

- Harry Wood 00:03, 13 September 2008 (UTC)

Language Namespaces have been implemented. Currently only: DE, FR, ES, IT and NL. Others at a later stage. Some template linking needs fixing. -- Firefishy 03:06, 3 October 2008 (UTC)

Could you briefly explain how to fix the template issue ? For instance, I cannot find the way to fix FR:About calling the template Template:Fr:HelpMenu. Pieren 15:55, 3 October 2008 (UTC)

Ok, thanks. For the others : to fix the template issue, replace the previous call {{Fr:template_name}} by {{Template:Fr:template_name}}. Pieren 10:21, 4 October 2008 (UTC)

Language Namespaces are now also included in the search results for anonymous and users who have not set their search preferences. - Firefishy 03:09, 10 October 2008 (UTC)

Since the implementation of the namespaces many talk pages can't be reached using the tabs at the top anymore, probably because they have a different name (De instead of DE). Maybe someone knows how to fix this. --Driver2 00:36, 12 October 2008 (UTC)

Can you give any page examples and I will check. --Firefishy 03:00, 12 October 2008 (UTC)

OK Spotted them and corrected now. --Firefishy 03:53, 12 October 2008 (UTC)

Language Menu

For to have a valid organisation between the different translations, I have written a template, who lists automatically all translations of every article in a language-menu. For to implementate it, I need a little help from a wiki-admin (copy this to this and this to this). Thanks, --Markus 15:16, 11 December 2008 (UTC)

PS: the template will also solve the problems described by Drbobo in the section before. --Markus 15:18, 11 December 2008 (UTC)

Is somebody working on the Bot for implementation? Thanks, --Markus 07:07, 3 April 2009 (UTC)

Namespace 'RU'

Hi! Is it possible to create a namespace "RU"? There is certain amount of pages in Russian language already. (including Ru:Main_Page) -- Zkir 13:02, 14 April 2009 (UTC)

Single sign on

Discussion moved. See Single sign on

update the mediawiki code

Its currently 1.4.14, update to latest (currently 1.6.7) -now on 1.8

...but at the current time we are now on 1.9 (Special:Version) but keeping up with latest MediaWiki code is an ongoing admin task I guess. -- Harry Wood 11:25, 17 October 2007 (BST)

Favicon

Put a favicon on the mediawiki [1]

DONE today : --Rickm 03:21, 18 September 2006 (BST)

Sub pages

Allow sub pages in the main namespace ($wgNamespacesWithSubpages[NS_MAIN] = true;)

DONE - Added by Steve --Dean Earley 10:01, 11 Jul 2006 (UTC)

Side bar

We can alter the navigation bar on the left of the wiki, to include a link to the map (and anything else you'd like), would you like it?

That would be a good idea in my opinion. Adding Portal:Users to it would be good. Bruce89 22:32, 23 Jun 2006 (UTC)

Now that we are on a newer version, this is very easy. Just need to edit MediaWiki:Sidebar (protected sysops only). We might want to think a bit about naming of these 'portals' though see Talk:Portal:Users. -- Harry Wood 18:04, 9 October 2006 (BST)

I havent taken into account the talk at Talk:Portal:Users but this was the idea I came up with a while ago User:Rickm/Sidebar. --Rickm 01:35, 10 October 2006 (BST)

I am now a wiki sysop, and I have made some improvements to the sidebar. Please take further discussion to MediaWiki talk:Sidebar. I'm open to suggestions for further improvement, although we also want a reasonable period of stability -- Harry Wood 19:50, 22 July 2007 (BST)

Top-left icon link

As discussed on Talk:Main Page#Top-left icon link, we should maybe link the big fat icon to the openstreetmap.org homepage (not just from the sidebar) -- Harry Wood 13:54, 25 Jul 2006 (BST)

Page vistor stats

Small thing. I haven't looked into it yet but its possible to turn on 'statistics gathering' in MediaWiki to see how many vistors, how many page views, etc. Say if you want it.

AJAX Search

The latest version of Mediawiki has an AJAX search feature, when you type something into the search bar it gives an instant view of what topics have the search string in their name. I'll show you an example, then if you want it, say.

Does it?, Wikipedia doesn't seem to have it, could you show an example? Bruce89 22:32, 23 Jun 2006 (UTC)

Here. It shows a result after three characters have been entered into the search bar, and updates as you type more. That site has a small user base, though we were wondering what the bandwidth effect would be with a larger user base.

Wow, that is quite something, it is a bit worrying though when it switches from the page to the search results. - Bruce89 22:50, 23 Jun 2006 (UTC)

Special Pages (general)

Just FYI, its possible to write special pages that are basically PHP scripts that can for example, pull information from the OSM database and display it in the wiki however we want. An example is this, its a calendar php special page, the information is generated from a PHP script that retrieves event information from a sql database.

Who gets permission to create those pages? We could do some neat stuff (e.g. coordinate conversion, or indexes of various items in the database) but if someone abuses it what's to stop them making the page impossible to revert?

Just to clarify, the way it works is the the PHP has to be uploaded by an admin, so any useful pages (after an admin's checking) I imagine will be included. Re: stopping abuse, the PHP code will be checked before hand, I don't forsee problems there. Please give more details on what you suggest if you still think its of value :) --Rickm 03:35, 18 September 2006 (BST)

To put it on the site, someone with access to the ftp server uploads it, anyone can write the PHP and give it to them though. The PHP can only be altered directly on the server. These 'MediaWiki Extensions' can result in a new page in the 'Special:' namespace like Special:Recentchanges, or alternatively they can make a new tag available for us on any wiki page (the tag invokes the php function). Could use this to suck in some interesting data. e.g. bring in a dynamic list of your mapping contributions, to appear on your wiki user page. The php code can't be altered through the wiki interface. --Rickm 03:35, 18 September 2006 (BST)

How does caching (sp?) work with the PHP pages? Can you set them to run the script no more than once a day for any given set of input parameters, for example?

There's no caching in built. We could write caching into a php script though

Wiki upload file types

Do we want to allow gpx and osm files so that you can store a village's data.osm in the wiki and others can render that without having to download from the main server. Maybe consider allowing xcf (GIMP) files so we can upload layered images, PDF files for rendered output, or even ZIP files for snippets of software. - from this message on the dev list

Problem is that xcf is the format is only documented in the GIMP's source code. Bruce89 22:33, 23 Jun 2006 (UTC)

Besides, as far as I know, SVG supports leyers as well as being vectorised. Use SVG instead of XCF --Skippern 00:30, 13 September 2008 (UTC)

ConfirmEdit Spam Captcha

The ConfirmEdit extension is now installed (See Special:Version) however it probably should be ugraded to a later version. The reason I say this is... I've tried to define a whitelist at MediaWiki:Captcha-addurl-whitelist. This should get picked up by the extension, meaning that we no longer get prompted when linking to openstreetmap.org URLs.

This isn't happening, and my hunch is that this whitelist feature was only added to the extension code recently, so we dont have it, until a System Administrator downloads the files (two files linked here) and plonks them on to overwrite the existing ones in extensions/ConfirmEdit directory on the wiki server.

-- Harry Wood 12:15, 9 January 2008 (UTC)

This feature was added to the Extension:ConfirmEdit SVN Revision @ 23122.

Syntax is as follows:
#   * Everything from a "#" character to the end of the line is a comment
#   * Every non-blank line is a regex fragment which will only match hosts inside URLs

-- Firefishy 16:06, 9 January 2008 (UTC)

Thanks both for your help in sorting this! --Richard 17:24, 9 January 2008 (UTC)

TomH did the heavy lifting. Can we Captcha-addurl-whitelist, informationfreeway.org, openstreetmap.nl, openstreetmap.de and opengeodata.org

Spam reverting feature

Create a button for reverting last edit of an article: to make removing spam easy.--Gerchla 10:08, 2 January 2007 (UTC)

The wiki community here is easily big enough to remove any spam pretty quickly when it occurs, so unlike on some wikis I've seen, spam really isn't a problem here. If you have this discussion with MediaWiki designers they will explain to you some subtle factors at play here. Did you consider, for example, that a malicious vandal might go clicking the 'quick revert' button everywhere? Basically you're not likely to come up with a silver-bullet wiki spam solution which MediaWiki developers haven't already thought about. But anyway as I say, we don't really have a problem. -- Harry Wood 19:42, 22 July 2007 (BST)

Wiki Search integration with mailing list

Make the wiki search page also display results for a search of the mailing list. Alternativly just add a link to the top of the search page they can click on to do that search on the list Nabble search link Gmane search link - both just talk, not dev atm. --Rickm 05:02, 18 September 2006 (BST)

Globe icons for OSM Map links

If we want to have a little globe icon appearing on the end of any link to a OSM map (i.e. slippy map), instructions are at User:Rick/Globe. It would appear like this, but a globe the link

Update search database

Update search database everytime when an article is changed: only need to scan current article. --Gerchla 10:08, 2 January 2007 (UTC)

SVG support

SVG support to the wiki as requested by Frankie It would allow SVG files to be uploaded, and then either pre-rendered by a server-side library, or displayed inline on the page. Details on the MediaWiki support are here:

http://meta.wikimedia.org/wiki/SVG_image_support and

http://www.mediawiki.org/wiki/Manual:%24wgSVGConverters

Community Portal

At these times OSM is not working the way it should I think. On sunday (2 days ago) the API was down for 6 hours; today the Yahoo maps don't show in potlatch... and a have difficulties to find a place to announce this, a sort of Community Portal would be nice as in wikipedia with a link to it on the menu. Where else can I write these things or have the chance to wake up someone pointing to a problem?? The status pages are only updated manually...

A Community Portal could be good for newbies too... --katpatuka 09:16, 25 December 2007 (UTC)

This is a discussion point in relation to WikiProject Cleanup (where we also look at things like the various purposes of wiki) One related discussion spills over onto Talk:Portal:Users for example, where I argue that "community" is not a useful word to use in a page name for a major page.

Please move this discussion to there. This page is for discussing technical (server code) wiki improvements. -- Harry Wood 10:26, 9 January 2008 (UTC)

$wgSpamRegex blocking all divs

The wiki spam regex $wgSpamRegex is set to block any use of <div>s in the wiki. In fact the setting we have at the current time is just: $wgSpamRegex = "/<div/"; (User:TomH tells me)

This gets in the way of various legit div usage. You can get around it. Some people figured out that <di<!-- -->v> works in most cases. However you can even just write <DIV> in upper case to get around it! It's a pain to make people figure this out. e.g. templates which work on wikipedia don't work here, unless you know this trick.

The main thing to block against spamwise is dubious use of the overflow style within divs. May as well just paste in this large example which includes protection against this "CSS hidden spam", as well as several other anti-spam tricks.

Spam isn't a big problem on this wiki (as mentioned above)

-- Harry Wood 10:33, 26 February 2008 (UTC)

This has now been removed. <DIV> can now be used. -- Firefishy 21:37, 5 September 2008 (UTC)

Extension:Babel

The OpenStreetMap-Wiki has users with many different native languages. It would be useful to have a way to tell others, what languages you can speak or at least understand. Somebody created OpenStreetMap:Babel templates some time ago and obviously tried to copy the system used on Wikipedia. But that system needs many, many templates. There's an easier way to achieve this. Mediawiki has now an Extension:Babel which allows the use of a parser function {{#babel: lcode | lcode | ... }}. That would make it possible to show your languages without creating masses of templates. Wouldn't that be useful to install? --::Slomox:: >< 13:56, 4 June 2008 (UTC)

Top-left icon link

Would it be a good idea if the OSM map icons in the wiki pointed to the OSM homepage? Presemably can be done easily? Blackadder 11:54, 10 Feb 2006 (GMT

Yeah I'd agree with that. The big fat icon in the top left should link to the openstreetmap.org homepage, which is now the map. To get back to the 'Main Page' you then click 'Help & Wiki'. To change the logo link, that's modification to skins/monobook.php -- Harry Wood 19:22, 22 July 2007 (BST)

Uploads

Would it be useful for this wiki to support sample data files, scripts, etc. At the moment, anything with a .txt filename (for example) is being rejected as "not a suitable image format". Ojw 12:28, 12 May 2006 (UTC)

In case this is still the case, its very easy to allow uploads for other file types, an admin with access to the server files can change localsetting.php. If the admin wants more help, ask me --Rickm 00:19, 10 September 2006 (BST)

Anonymous wiki editing

Is there a good reason why visitors aren't allowed to edit the wiki without logging in? I, for one, would have corrected a few typos on the wiki when I first visited it, but I did not because I was not allowed to edit without first creating an account. The barrier to entry for participation should be kept to a minimum. This project is still in its infancy and needs all the support it can get. Vandalism can easily be reverted. Novem 02:22, 27 November 2006 (UTC)

I'm a big fan of openly editable wikis but...

In this case the wiki is not the project. Unlike many wiki projects, we are not aiming to massively encourage contribution to the wiki content from any newcomers who want to chip in. We are more interested in having the wiki as an effective communication mechanism to bring the existing OpenStreetMap community together (people who contribute to the map and/or OSM software development) This purpose would not be served well by having lots of IP addresses showing up in recent changes instead of usernames. The fact of the matter is many OSM mapper/developers wouldn't bother logging in to the wiki if we allowed anon editing.

Of course the best thing would be if we see usernames which are in alignment with those of the main OSM system (See Single sign on)

-- Harry Wood 15:11, 28 January 2009 (UTC)

Two accounts?

From what I understand, I need two accounts: one on wiki.openstreetmap.org to edit the wiki, and one on openstreetmap.org to upload data and edit the actual map. Why not use a single account for both the wiki and the editor? That would be a lot simpler for the users. Also, there would be no need to require an email address for an OSM account anymore. If the OSM server really needs to communicate with me, it can leave me a message on my talk page just like they do on wikipedia. Novem 02:22, 27 November 2006 (UTC)

Not just two. We have about five or six different types of Accounts! Unification of the logins/accounts would, of course, be a good idea. It has been discussed before, but it's a bit of development (or at least technical tinkering effort) which hasn't happened yet.

The wiki doesn't say much about this. I know one proposal was to make everything support 'OpenID'. (google for OpenID discussions) Let's create a page called "Single sign on" to describe where we're at. -- Harry Wood 15:48, 15 October 2007 (BST)

Navbars at the top

can a wiki admin put the "Map,Upload,Help,Blog,Shop,Donate" links into MediaWiki:Sidebar so that they're part of the wiki interface? Currently they use up a lot of space at the top of the main page (so the "real" main page is about halfway down a laptop screen) Ojw 23:33, 25 June 2007 (BST)

thanks to dee for adding that Ojw 23:34, 25 June 2007 (BST)

For further discussion of that see MediaWiki talk:Sidebar. -- Harry Wood 14:57, 15 October 2007 (BST)

CSS for source code

There's a nice style applied to source code snippeds inside pre tags. But i didn't find a way to combine it with the source tags. Is it possible to set the CSS of the source tags to the same as the pre tags? For example, here i had to set the XML code snippets into divs with CSS attributes to make them appear in that nice gray box. --Florianschmitt 21:31, 6 September 2008 (UTC)

Syntax highlighting is done by this wiki extension which we have installed : http://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi

I just took a look at the usage examples. I notice the rendered HTML on that site comes out with <pre> tags, which is different to the way it is behaving here. And it is the CSS for <pre> tags which gives the grey dotty box style. So I imagine we might fix this if we were to re-install a later version of the extension (I'm guessing that will cause it to always wrap the code snippet in a pre tag) Might be a better solution than trying to devise a css rule for the current output. -- Harry Wood 20:19, 7 September 2008 (UTC)

You may use de:Code im Wiki darstellen. --Markus 00:21, 26 September 2008 (UTC)

Is there still an issue with the extension? The latest stable version is installed. -- Firefishy 09:52, 26 September 2008 (UTC)

For me it's fine, thanks! (but the documentation, I made it in German, may be somebody may translate it? --Markus 17:18, 27 September 2008 (UTC)

The issue Florian pointed out is that XML source such as the following...

<!-- my comment -->
<xmlroot>
  <myelement myattribute="Hello">World</myelement>
</xmlroot >

...is not getting a grey dotty box around it. This is because our extension is not spitting out a pre tag around the output for some reason. Strangely on mediawiki.org it does. Thought it must be a later version. Hardly a major priority though :-)

-- Harry Wood 13:07, 29 September 2008 (UTC)

Fixed, Revision 37495 is known good. -- Firefishy 14:59, 29 September 2008 (UTC)

Allow use of images from wikimedia commons

There's a suggested config change over at Talk:Collaboration with Wikipedia#Usage of Wikimedia Commons, which I guess would make sense. Newly available in the v1.13, it allows us to use images from wikimedia commons, and fetches description pages automatically. -- Harry Wood 12:09, 23 September 2008 (UTC)

I support this suggest. --Kolossos 17:47, 23 September 2008 (UTC)

Is there a test implementation so that we can see that itr works? I try it i.e. on Toolserver wiki, without luck. --Kolossos 12:28, 29 September 2008 (UTC)

I support this suggest. --John07 19:14, 23 September 2008 (UTC)

Yes Harry, it promise a lot of simlplification. --Markus 17:21, 27 September 2008 (UTC)

This would be awesome, enable! --Ævar Arnfjörð Bjarmason 12:37, 29 September 2008 (UTC)

Do we want to be reliant on Wikimedia Commons? --Firefishy 14:52, 29 September 2008 (UTC)

[[Image:SomeImageOnCommons.jpg]] automagically gets linked, local caching is optional. --Firefishy 14:52, 29 September 2008 (UTC)

If I look on pages like Dresdner_Heide,I would say that it is useful for both projects. There are also images for city-districts[2] on commons which could be interesting for both projects.

Commons is stable enough so that the depency should be no problem. Ok there will be problems if an image will delete on commons (i.e. if the copyrights are not ok), but this also protects OSM against legal problems. And the solution doesn't mean that all images need to be saved on commons.

Commons-example-image:

--Kolossos 18:09, 29 September 2008 (UTC)

Ping? --Kolossos 09:09, 13 October 2008 (UTC)

Pong, this needs wider discussion. May I ask you to bring this up for discussion on Talk Mailing List? -- Firefishy 10:04, 13 October 2008 (UTC)

Couple of reasons why we might not want this:

• It means we're reliant on Wikimedia Commons. If those servers are offline or slow, then our wiki is adversely affected
• It serves to make this wiki look more like wikipedia.
  • This wiki is not wikipedia. Some people seem to expect the same rules to apply and the same super-keenness on, for example, decisions by voting. Anything which makes this seem more like wikipedia might worsen this problem.
  • As a more concrete objection though, we actually have more strict rules (or community acceptance tendencies) regarding copyright free sources of maps/map data. For example wikimedia commons has a map of london boroughs. While it might be useful for us to place this on our wiki for coordinating mapping, we don't do that because we want to encourage people to build borough boundaries data without copying, hence our best equivalent is Image:London-borough-boundaries.png

...just playing devil's advocate though really. I personally don't object strongly to the idea. Then again I don't really see why so many people seem to think it will be wonderfully useful!

-- Harry Wood 12:48, 1 December 2008 (UTC)

Things have moved on: Collaboration_with_Wikipedia. Wikipedians are not concerned to work with OSM at least. --Malenki 12:18, 16 April 2009 (UTC)

Hi Harry! we have thousands of pictures in Commons. When we can use it without copying to our Wiki, and without clearing all the copyright-stuff - it will be a very simple way to use more pictures in our Wiki! --Markus 23:09, 8 December 2008 (UTC)

Hi Harry, did you add the code to the localSettings.php? How it works to link pictures from commons? --Markus 00:08, 28 January 2009 (UTC)

No, this has not been enabled. I personally do not like it. How long does it really take to upload a file from Wikicommons and add attribution? 30 seconds? Do we really want to "pollute" our namespace with everything in Wikicommons? I am happy to change my mind if there is a real debate, as requested earlier. -- Firefishy 00:54, 28 January 2009 (UTC)

If the images are to be properly categorized and licensed (sometimes requires version history, author(s) ...) and so on, I guess it takes at least three minutes -- which is 170 seconds too much, as documenting stuff in the wiki has to be as quick and easy as possible to ensure that people actually bother to do it. There is another problem with importing images to our wiki: Finding those images. Images on commons are easy to find, because Wikipedia articles use them, because they are usally well categorized etc. So people likely will not use our wiki to find illustrations, which will probably result in duplicates. Last but not least, images on Commons often have helpful captions in multiple languages, information about time and place of creation etc. Copying this information requires additional effort, and it will not be updated automatically when e.g. the caption is translated to additional languages on Commons. --Tordanik 11:11, 28 January 2009 (UTC)

Personally, I really like the idea - it's pretty easy to add and should not cause any performance problems. While I do see possible downsides, I for myself think the positive aspects outweight them. --Avatar 06:55, 30 January 2009 (UTC)

+1 from me. --seav 09:06, 30 January 2009 (UTC)

+1 from me. Would save a lot of work --Malenki 12:18, 16 April 2009 (UTC)

Hmmm "pulluting" the wiki namespace, is another downside I hadn't really thought of. What happens when a locally uploaded image has the same name as a remote image? -- Harry Wood 11:05, 30 January 2009 (UTC)

I would appreciate it if someone could test Wikimedia Commons Foreign Repos on a test wiki of theirs. Particular cases: 1) Existing same name in OSM wiki and WM Commons. 2) Upload to OSM wiki with a name that exists on WM Commons. 3) Resolving existing? conflicts. 4) Difficult one, performance impact. 5) Possibility of using a special namespace for the Wikimedia Commons items. WMC:Image:xxx unlikely, but worth a look. 6) Other?. http://commons.wikimedia.org/wiki/Commons:Reusing_content_outside_Wikimedia#Own_MediaWiki_installation -- Firefishy 12:13, 30 January 2009 (UTC)

First of all: Wikimedia Commons is a shared file repositorium for all, not for Wikipedia/Wikimedia projects alone. IMO it does not make sense to duplicate content it if could be used from Commons. Now your questions:

1. The local file has priority over a file from a shared repo. Always. Same behaviour as in Wikipedia.

2. See 1. At time of upload to OSM wiki this local file will become priority.

3. I do not understand the question. Which conflicts?

4. No performance impact for OSM wiki. And the Commons servers are fast enough to handle the requests of OSM wiki. And they have a lot of space: actual upgraded to 24 TB in total (5 TB used)

5. As far as I know not possible.

You can test the function on http://translatewiki.net , an independent wiki used for localization of MediaWiki, i.e. http://translatewiki.net/wiki/User:Raymond. (to clarify: I am MediaWiki developer, Wikimedia Commons sysop and Translatewiki server admin) Raymond de 15:37, 31 January 2009 (UTC)

Locally-uploaded files always override the Commons files. --seav 05:59, 31 January 2009 (UTC)

Please can somebody implement this? Thanks a lot! --Markus 07:00, 3 April 2009 (UTC)

BTW: It's not in "Test" anymore, but already in the stable. So the right version of Mediawiki and PHP is here already. All neccesary is some additional lines in the LocalSettings.php. See http://www.mediawiki.org/wiki/Manual:$wgForeignFileRepos#Using_files_from_Wikimedia_Commons_:_ForeignAPIRepo ---jha- 12:04, 3 April 2009 (UTC)

ENABLED! - If it causes problem we will have to rethink. - Firefishy 18:08, 16 April 2009 (UTC)

Cool. I must say I was always tempted to ignore this request until somebody actually came up with some concrete examples for why it will be so useful. Kolossos is the only one who has given an example above, and that example is to bring in potentially derived map images! ([3])

Please do not use this new feature to bring in map images, unless they meet the OpenStreetMap community's strict criteria for 'free' maps. Anything showing administrative boundaries is probably not strictly free, since it will have been created by copying off copyrighted maps (I'm not saying the wikimedia community is wrong in labelling it as a free image, just that we at OpenStreetMap do not like to derive our data from anything like this)

Of course that is not an issue with this new feature as such, but something to be very aware of if you were planning on going on a commons importing rampage. I can think of examples where this new feature will be useful. e.g. I just decorated Tag:shop=garden_centre by doing a quick search on commons.

-- Harry Wood 18:28, 16 April 2009 (UTC)

I want to say thank you, too (and agein :) ). The first page I used this new feature: DE:Tag:historic=castle --Malenki 19:05, 16 April 2009 (UTC)

Thanks a lot! --Markus 19:24, 16 April 2009 (UTC)

Interesting little problem related to this. If look at the old version of Key:crossing examples, before I fixed it, it's picking up on images from commons, where there used to be 'red link' stub references to non-existent images before. In these cases it might happen upon an image which is relevant, but in the case of Lollipop.jpg it might not be! Easy enough to fix over time though, so if you see a seemingly random irrelevant image on the wiki anywhere, this might be the cause. -- Harry Wood 14:09, 25 April 2009 (UTC)

DynamicPageList Extension

http://www.mediawiki.org/wiki/Extension:DynamicPageList This feature would help keeping statistics up-to-date. The user changes eg. street-status on his 'hometown' page and the country overview is dynamically updated. -- Kannix 18:09, 7 December 2008

While I see the benefits for sure, DPL can kill even servers with good performance pretty fast. --Avatar 06:52, 30 January 2009 (UTC)

Managing Map Features using Semantic MediaWiki

There is a proposal for using Semantic MediaWiki to manage map features on the OSM wiki. The concept is explained here. It promises

• to reduce the amount of redundant information about map features
• to reduce the amount of summary tables which have to be maintained manually
• to automatically generate a machine-readable map feature list for editor and validation software of the OSM project

As proof of concept, we've migrated a small subset of the current OSM wiki, see this dev wiki.

I'd like to start a discussion about what other contributors to the OSM wiki think about this new concept, whether the existing OSM wiki should be migrated to the new structure and how this could be done.

Gubaer 14:07, 18 January 2009 (UTC)

I'd love to see us starting to use something like that. Currently, there is a lot of duplicate and sometimes inconsistent information in the wiki. The Semantic MediaWiki could really help to reduce those problems and reduce the effort to create new feature documentation, proposals (updating all those proposal-related tables is a lot of work, too) etc. I'd also appreciate having machine-readable information available, thus I absolutely support your efforts.

However, this page seems suffer from low visibility, so I wouldn't expect you to get many answers here. Is there a reason why you aren't discussing this in a more populated place, such as the mailing lists? --Tordanik 22:46, 23 January 2009 (UTC)

I also sent a mail to talk@osm but a discussion did not take off. I guess the interest in the communitity for this proposal is low. Or did you have another mailing list in mind? Gubaer 09:54, 24 January 2009 (UTC)

Well, I thought of talk, but as you've already done that, you might try dev this time: It has less traffic and you'll find most of the technically skilled project members there. I suggest that you clearly state what you intend to do, what kind of support you need to do it and what decisions need to be made. (Which, of course, assumes that you know that.) There wasn't really opposition to the idea on talk as far as I can see, so probably all it will take is someone who actively pushes the idea forward. --Tordanik 13:46, 24 January 2009 (UTC)

Yes, I know (or at least, I think that I know ...) what the next steps should be. The most critical thing is getting SMW installed on the production wiki and to get OSM sysadmins commited to keep it up and running. It's critical because it might be risky. We don't know yet enough about the run time behaviour of a SMW combined with templates and parser function, in particular the run time behaviour on the OSM backend hardware whose capacity seems to be limited. I contacted OSM sysadmins directly but no luck so far. My best guess is that nobody wants to take the risk. Gubaer 14:47, 24 January 2009 (UTC)

I have a remark regarding the proposed namespaces. As far as I know it is technically not possible to create a lowercase namespace. The first letter will always become uppercase. For example pt-BR becomes Pt-BR. --Wimmel 20:50, 27 January 2009 (UTC)

AFAIK, you can define namespaces consisting of lower case characters only and you can declare link using lowercase only namespaces (i.e. [[de:FooBar]]), but such a link will always result in a page whose title starts with an uppercase character De:FooBar.

This is not a problem, however. A link [[de:FooBar]] leads to the page De:FooBar. So does a link [[De:FooBar]]. A link [[DE:FooBar]], however, leads to a page DE:FooBar which is not the same as De:FooBar.

Using lowercase characters for language prefixes is therefore both consistent with ISO standards and with naming conventions for Wikimedia page titles.

Gubaer 12:30, 28 January 2009 (UTC)

Yes correct. There might be a way to display the title in lowercase (see iPod for an example), but the URL will not change. --Wimmel 20:56, 28 January 2009 (UTC)

Edit link for each row in a table

I would like to see an (option for) edit link for each row in a table. Very usefull for large tables. --Lambertus 09:56, 23 January 2009 (UTC)

Why: Recent changes by RSS give me a Access Denied Error?

--Zapfen 11:22, 7 April 2009 (UTC)

Access is denied because they overload the tiny Wiki server we currently have. Access is enabled via Google Reader at the moment. Sorry. -- Firefishy 18:27, 16 April 2009 (UTC)

Show environmental data / pollution on an open source map - grass roots collected, edited & owned!!

I'm interested in a popular idea - to have some sensor hardware recording the environment & pollution etc and sending that with the GPS trace to be displayed as an overlay (layer?!?) on a basic map on the web.

Basically displaying the ecological state of the world around us! a powerfull tool....

I am interested in collecting environmental data such as temperatures, CO2 levels, Volatile Organic Compounds (VOC'S) etc..., also water ( creeks, rivers, ocean, tapwater!!!) Also particulates & heat variations/islands in cities, and liquid sensors for water data!

If your interested - Talk[ http://wiki.openstreetmap.org/wiki/User_talk:Balingup]

and we could look at some options of how to do it, and where etc.