Talk:Wiki/Archive 1

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)

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

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

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)

Wiki Search. Install a search plugin?

In Steve's old mailing list post he suggested a wiki cleanup was needed, which cannot be denied, but he also seemed to be particularly peeved by failure to find things. This could partly be blamed on the search function itself.

MediaWiki search stinks or at list it's a bit hit and miss. This comes to my attention every now and then, usually in cases where I can easily create a new handy redirect to remedy the situation for that keyword. But that's not solving the search problem overall. I've no idea why a search for 'Getting' turns up nothing. Getting The Source, Getting Involved, Getting Data, hello??. Sometimes search results come in a funny order, seemingly based partly on the order pages were created or something. Sometimes I just wish I could do more powerful google style text searches. So...

The recommendation seems to be to install Lucene or Spinx plugins.

-- Harry Wood 14:59, 14 May 2009 (UTC)

User:Firefishy has ENABLED lucene search plugin.

That was quick!

Working much better: search for 'Getting'

Kick ass!

-- Harry Wood 17:03, 14 May 2009 (UTC)

enabling email notifications

hi. i wanted to argue about enabling of e-mail notification functionality whenever somebody edits a page on user's watchlist.

on wikipedia it was disabled for a long time because they cited performance concerns. if that is also the reason for osm wiki, i have some suggestions :)

my watchlist produces on average 1-2 notifications a day. current setup requires me to manually check my watchlist every now and then (which i can't always do and often forget), older changes wanish from the watchlist and it seems to me that watchlist 'diff' links only show the latest change to the page (thus i often miss prior edits). that is very, very inconvenient and i constantly miss edits that i'd like to know about. what about enabling this feature, but leaving it to 'off' by default, so users would have to explicitly enable it - and if there still are performance concerns, what about some arbitrary limit, like "you can only enable email notifications if your watclist is < 50 pages" ? i believe that would notably improve quality of the contents - and i wouldn't have to hammer servers by viewing watchlist manually when that's not needed ;)

at first i assumed that this functionality is enabled, thus i left comments on talk pages and wondered why nobody responded... so i'd like to propose enabling of this feature. and, after all, even wikipedia enabled it... --Richlv 15:11, 3 July 2009 (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

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)

• +1 -- Hind 20:50, 21 July 2009 (UTC)
• Please add Russian namespace --vvoovv 21:35, 21 July 2009 (UTC)

Added and live, search preference need to be reset by user. --firefishy 22:51, 21 July 2009 (UTC)

Thanks! -- Zkir 06:13, 22 July 2009 (UTC)

multilingual name spaces

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)

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)

Done -- Firefishy 14:49, 27 March 2010 (UTC)

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

Anyway, might it be possible to add an RSS feed acess to the last changes in my watchlist? Would be good to notice changes http://meta.wikimedia.org/wiki/Syndication_feeds. The problem is that otherwise, the people from the mailinglist get out of sync with the "normal" people using the wiki. Might it be possible to use proxys/chaches/...? --!i! 12:06, 29 May 2009 (UTC)

It seems the RSS feed is working now. (great!) --Gwilbor 11:08, 4 March 2010 (UTC)

Link to Blog planet

In the navigation bar on the left side is a link to the blog of http://www.opengeodata.org/ . I propose to change it to the blogs collection http://blogs.openstreetmap.org/ Alternative would be a Blogs page. --Kolossos 20:36, 21 June 2009 (UTC)

Well the value of linking to opengeodata.org is that it's supposed to be the "main" blog with openstreetmap news. It's potentially a place to follow the important news announcements whereas blogs.openstreetmap.org is a different thing. Which of those is more important and deserves a prominent link there? -- Harry Wood 08:32, 22 June 2009 (UTC)

On my todo list is to create a generic blog for OSM. something like blog.openstreetmap.org., opengeodata.org belongs to SteveC and the Foundation has requested me to create a new one. Open to all for blog post submission. --Firefishy 09:57, 22 June 2009 (UTC)

Note.. just to be clear, I believe OpenGeoData.org is open to all for submission currently too. --Firefishy 09:59, 22 June 2009 (UTC)

Cool. Sounds good. I remember there was a mailing list discussion about it sometime ~4/5 weeks ago too.

Related to this, I'd quite like to somehow obviate the need for a wiki-maintained news section on the main page (Talk:Main Page#news)

Also related... in an ideal world somebody would to do this: Things To Do#Task: Mailing list weekly-digest Maybe that's more likely to happen on a new blog.openstreetmap.org

-- Harry Wood 11:23, 22 June 2009 (UTC)

Blog link now leads to blog breakout page on wiki -- Firefishy 14:49, 27 March 2010 (UTC)

Russian SideBar have links to English pages

Now we have not right links in Russian SideBar. There are links to English pages unstead links to Russian pages. For example "Справка"(HELP) must be http://wiki.openstreetmap.org/wiki/RU:Help:Contents unstead http://wiki.openstreetmap.org/wiki/Help:Contents -- User:Calibrator 23:05, 28 August 2009 (UTC)

Anybody can fix it? --Calibrator 13:46, 13 October 2009 (UTC)

I don't know of an easy way of fixing sidebar links to do this. We'd have to do a little hack in the wiki code I think. -- Harry Wood 09:36, 15 October 2009 (UTC)

In accordance with http://www.mediawiki.org/wiki/Manual:$wgForceUIMsgAsContentMsg, it need change only one string in LocalSettings.php file. Never edit DefaultSettings.php; copy appropriate lines to LocalSettings.php instead and amend them as appropriate.

$wgForceUIMsgAsContentMsg = array();

change to

$wgForceUIMsgAsContentMsg = array( 'mainpage-url', 'portal-url', 'mapfeatures-url', 'helppage' );

--Calibrator 20:49, 17 October 2009 (UTC)

Guess User:Firefishy's done that for you then. Seems to be working now -- Harry Wood 08:47, 23 October 2009 (UTC)

No, not enabled yet. Enabling $wgForceUIMsgAsContentMsg requires changes to the language templates which I am loath to do until we have moved to a new server. It also needs testing. -- firefishy 09:32, 23 October 2009 (UTC)

Ah it was the uselang URL param someone's added, e.g.: http://wiki.openstreetmap.org/index.php?title=RU:About&uselang=ru I hadn't noticed that before. So the sidebar links are displayed in the right language when that happens, but they're still linking back to the English page. -- Harry Wood 10:12, 23 October 2009 (UTC)

So just to re-iterate.... Firefishy will look into this later after we have moved server. -- Harry Wood 17:27, 16 November 2009 (UTC)

When Server will be MOVED? --Calibrator 06:19, 15 January 2010 (UTC)

Enabled - $wgForceUIMsgAsContentMsg = array( 'mainpage-url', 'portal-url', 'mapfeatures-url', 'helppage' ); -- Firefishy 17:32, 10 March 2010 (UTC)

Yey, finally! Can you also add some Polish translations below?

• MediaWiki:Mainpage-url/pl (http://wiki.openstreetmap.org/wiki/Pl:Main_Page?uselang=pl)
• MediaWiki:Mapfeatures-url/pl (Pl:Map Features)
• MediaWiki:The map/pl (Mapa)
• MediaWiki:Map Features/pl (Znaczniki mapy)
• MediaWiki:Shop/pl (Sklepik)
• MediaWiki:Donations/pl (Darowizny)
• MediaWiki:Portal/pl (Projekty)

Yarl ✉ 18:33, 10 March 2010 (UTC)

DONE -- Harry Wood 00:54, 11 March 2010 (UTC)

Images with link parameter

At Wikipedia, it's possible that images don't link to their description page, but to some other page instead (see: wikipedia:Wikipedia:Picture_tutorial#Links). It seems that this doesn't work here:

This feature would be useful for things like icons in key/tag description template boxes. Can it be enabled somehow? --Tordanik 12:45, 29 September 2009 (UTC)

Yes that's introduced in MediaWiki v1.14 onwards.

In the meantime the best workaround is to use the imagemap extension e.g.:

<imagemap>

Image:Mf_node.svg

desc none

default [[Node]]

</imagemap>

...gives you a clickable image like this

Upgrade to version 1.14 will happen at some point I guess (see Special:Version) Maybe firefishy is planning a move to new hardware at the same time (?)

-- Harry Wood 14:04, 29 September 2009 (UTC)

Already enabled for ages, see Beginners' Guide as example. Upgrade to MW 1.14 not required. -- firefishy 09:30, 23 October 2009 (UTC)

DONE: Yes imagemap's been enabled for ages. But now we're on v1.15 Tordanik has the feature he was asking for (try clicking ) Hurrah! -- Harry Wood 15:32, 24 February 2010 (UTC)

Cool, let me add a "Thank you" to this thread. :) I've noticed that it's already being used for our icon templates: --Tordanik 20:40, 14 March 2010 (UTC)

monobook.js

Hi. My monobook.js doesn't seem to work (yes, I'm sure I've purged the cache). I wonder if anyone has succeeded in using it on this wiki. GranD 11:54, 17 November 2009 (UTC)

By default wikis have this disabled ($wgAllowUserJs=false) I guess that is the case here. -- Harry Wood 01:14, 18 November 2009 (UTC)

OK. Why not turn it true? GranD 09:03, 18 November 2009 (UTC)

Enabled along with $wgAllowUserCss -- Firefishy 13:28, 25 February 2010 (UTC)

Printing not possible

If I try to print a Wiki-Page, the content is too far on the left! CSS-Code:

#column-content {
margin-left:-12.2em !important;
}

--t-i 16:45, 1 March 2010 (UTC)

Should be fixed now. -- Firefishy 17:04, 1 March 2010 (UTC)

Namespace RU and templates

Hi! we have the following problem. Templates in the namespace RU include pages, not templates. For example {{Template: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)

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. no.wiki.openstreetmap.org 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)

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)

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)

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)

Single sign on

Discussion moved. See Single sign on