From OpenStreetMap Wiki
Jump to: navigation, search

Namespace RU and templates

Hi! we have the following problem. Templates in the namespace RU include pages, not templates. For example {{RU:abcd}} includes "RU:abcd" but should include "Template:RU:abcd". Compare with templates with prefix Fi: {{Fi:abcd}} includes "Template:Fi:abcd". Could this problem be helped? -- Zkir 15:59, 27 August 2009 (UTC)

Use {{Template:RU:abcd}} -- — Verdy_p (talk) 23:41, 17 May 2016 (UTC)

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 Languages Template which uses the PageName.language format. --Dean Earley 11:32, 10 Jul 2006 (UTC)</s>

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 technically more elegant solution for creating parallel wiki knowledge-bases 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 different 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)

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)
Just a thought, since we are getting more pages using various language pre-fixes, and we can probably find a way to set language variables in pages without such pre-fixes, could we set up a system where i.e. would point to all pages within the Norwegian namespace or with the Norwegian language set in a variable? This would of corse be a read-only wiki, and when linking to non-Norwegian pages would fall back on a default language. Pushing the edit button on this wiki for a tag coming up in the wrong language should then give the user (if registered as a wiki editor) the edit window for the Norwegian namespace here on the main wiki, or maybe just an informative pop-up about how he can translate the page. I can imagine Norwegian, Swedish and Danish use the other two and English as possible fallbacks, Portuguese and Spanish would fall back on each other, etc. As a Norwegian/English/Portuguese user I can (with some limitations) be able to read and understand Swedish, Danish and Spanish. I think something like this can lower the barrier of entry for non-English contribution to OSM as a whole. --Skippern 13:03, 31 December 2009 (UTC)

More info on the new Wiki Translation page -- Harry Wood 08:42, 3 June 2009 (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)

There's a new page Wiki Translation which should be developed to give more help and also track progress of translation efforts. It should also be translated I guess! -- Harry Wood 08:37, 3 June 2009 (UTC)

Well, I'm not in favour of a wiki familly. I think too that the common basis of English pages and the use of the {{language}} template are good solution for this wiki. But, there is a poor use of namespaces : only 6 namespaces are created for languages (ES, DE, FR, RU, NL) and very few and bad used. I think that the upercase FR was for the country and the lowercase fr for the tongue. Maybe i'm wrong...

For the mediawiki program, the NN:XXXX syntax is not enough to get a namespace.

With a generalized creation of namespaces, the use of internalization templates (recognizing the namespace) should help. In the mediawiki programe, the {{SUBJECTPAGENAME}} and the {{NAMESPACE}} are powerfull keywords for templating. e.g. in a template lg_link {{#ifexists:{{NAMESPACE}}{{{page}}}|[[{{NAMESPACE}}{{{page}}}]]|[[{{{page}}}]]}} would produce a quick link to the translated page if it exists or to the English page.

Adding namespaces to the wiki is very easy.

In the same way, the help namespace is not very used, a WikiProject namespace should be welcome now that they are growing in number. Maybe they are other namespaces that could be created.

--FrViPofm 15:23, 26 February 2010 (UTC)

Single sign on

Discussion moved. See Single sign on

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

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)

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)

Database is updated daily. Creating the search DB is fairly intensive task -- Firefishy 14:50, 27 March 2010 (UTC)

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)


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 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)


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 to edit the wiki, and one on 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)

DynamicPageList Extension 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)

Relicense GFDL material while we have a chance?

Are we going to relicense GFDL-licensed pages such as Free The Postcode UK Coverage, WikiProject Germany/Landkreise and WikiProject United Kingdom Long Distance Paths to Creative Commons during the relicensing window? --Wynndale 15:59, 20 June 2009 (UTC)

No big deal really. Those pages are just stuff copied from wikipedia. The most helpful thing to do would probably be to copying the pages again from wikipedia some time, to update them. They pages should clearly indicate that they are based on wikipedia, and therefore licensed under whatever content license wikipedia is requiring. -- Harry Wood 10:44, 21 June 2009 (UTC)

Russian spammer

Do we want to enable the SpamBlacklist extension or block IP addresses? - User:Wynndale 13:10, 11 July 2009

Is there a problem? We can block by IP address without installing anything -- Harry Wood 14:53, 3 August 2009 (UTC)

New Skin

Any chance of someone popping the new Vector skin on the Wiki which is developed by the Wikipedia Usability Initiative. Read the skins bit. It's really, really nice(I think!) & looks good. We're currently working on implementing it as default over at Wikinews. Just when someone gets a chance. Cheers! Tristan Thomas 22:33, 1 August 2009 (UTC)

Yes, will install once MW 1.16 goes stable. -- Firefishy 14:49, 27 March 2010 (UTC)


Would there be interest in getting SineBot over here? Tristan Thomas 22:11, 7 August 2009 (UTC)

Could be good, although the wiki server struggles a bit sometimes so it would have to be only running during quiet periods. -- Harry Wood 18:59, 16 August 2009 (UTC)
Would love to have SignBot run against the OSM wiki. -- Firefishy 13:46, 18 May 2010 (UTC)

Direct image URL whitelist

A long time ago we enabled direct image URLs for mapnik tiles. At the time MediaWiki only allowed a single domain to be whitelisted for this, but things have moved on a little now. wgAllowExternalImagesFrom can now be an array, or even better, the image URL whitelist can be wiki maintainable (but restricted to admins normally) by setting [1] to true. I'd recommend doing this.

There are some minor disadvantages/considerations when allowing external image URLs. See this manual page ...largely written by me actually :-) These are reasons for not allowing any direct image URL. But there's little harm in being quite liberal with a whitelist. The specific use which made me think of this again is discussed here: Talk:Addis Ababa/Yahoo, but there's all sorts of image trickery which would be easier with direct URLs. e.g. We could allow people to point the wiki directly at OJW's service.

-- Harry Wood 19:19, 16 August 2009 (UTC)

PL: namespace

Hi! Can you add PL: namespace for Polish language pages? I want to fill documentation in Polish but I don't want to move them after new namespace. Yarl 15:14, 27 September 2009 (UTC)

There's a handful of Polish pages already (pages with Pl: prefix) I think grant is setting up new language namespaces if there's a large number of pages already translated. Not sure if this qualifies. -- Harry Wood 23:01, 28 September 2009 (UTC)