Talk:Wiki/Archive 6

A language bar for Talk pages.

I wonder if it would be possible to develop a "language bar" for Talk pages, similar to the one we see on each Key/Tag page, capturing active Talk pages in other languages. We would have a full picture of the discussion conducted by all the people around the world interested in the topic. The meaning of what someone wrote in a different language will enable Google Translate. --Władysław Komorek (talk) 18:31, 18 February 2019 (UTC)
PS. I think I found the answer. We only need to add the "language bar" to all Talk pages in English using the bot. --Władysław Komorek (talk) 18:41, 18 February 2019 (UTC)

Wouldn't it make sense to wait for others to voice their opinions before adding Languages templates (and {{Talk}}, which was so far largely unused) to hundreds of pages? And in particular, please don't create new talk pages with zero content. Being able to see at a glance that the talk page link is still red is an useful feature. --Tordanik 18:20, 19 February 2019 (UTC)

You're partially right. But I added the Languages templates and and {{Talk}} to several articles, not to many, with zero content as a test, to make it easier to add comments by the "shy" person. :) If you do not like it, you can always delete it.

The addition of Language template allows us to see visually whether there are any comments in other languages than native ones. Before, simply, it was too time-consuming to look for other opinions. :(

BTW I found that the {{Talk}} template is very useful for novices. --Władysław Komorek (talk) 19:30, 19 February 2019 (UTC)

@Tordanik: I understand your concern about {{Languages}} and {{Talk}} on Talk pages.
Let me introduce my point of view.
All the time we have a problem with the lack of opinions from the mappers. We have thousands of OSM users, but only a dozen or so participate in discussions on Wiki articles. Most of them write on forum related to OSM. Many of them have very helpful suggestions, or describe various ambiguities in Wiki tag descriptions. From conversations with Polish users I learned that they avoid writing on the Wiki because: they do not really know how to do it, they are afraid of ridicule, they prefer to write in their language.

I considered the possibilities of how to change it and increase the involvement of Polish users and users writing in other languages.
Maybe this is not the best way (you can always improve/delete), but it's always necessary to start somewhere.
I do not think that this type of technique must be widely discussed as Proposal.
So I started by adding these templates to every Talk page translated into Polish, as well as to more important Wiki pages and their translations.

1. {{Languages}} for each Talk page of the translated article, in every translated language, as in the translations of Wiki pages.
   This allows us to quickly find the opinions of other users.
   The Talk page link in red is not very useful, as are the lack of links for Talk pages.
   
2. {{Talk}} (the context of this template can be configured for each language).
   I found this template, unnoticed by most of us, and I came to the conclusion that it could be a very useful, practical and welcoming template for all of us on Talk pages.

Summarizing

I suggest developing this solution and its further improvement.
If, after a few months, it turns out that they are harmful or misleading additions, I will not object to using the "bot" and delete them.
PS. I received a nice email yesterday thanking me for adding {{Talk}}. --Władysław Komorek (talk) 08:28, 22 February 2019 (UTC)

BTW Maybe someone knows how to open an additional window with the Talk page translation into the selected language. Similar to {{GoogleTranslate}}
That would be a very useful "button", maybe within {{Talk}}. --Władysław Komorek (talk) 11:52, 22 February 2019 (UTC)

IMHO we should remove all of the {{Talk}} tags. The OSM wiki has never had problems with the integration of noobies. It's a waste of space to repeat our basic rules again and again.--Steenbuck (talk) 22:20, 24 February 2019 (UTC)

"The OSM wiki has never had problems with the integration of noobies" I am not so optimistic, many people had trouble for many reasons. But mass adding this template spam everywhere without prior consensus is not OK and can and should be reverted Mateusz Konieczny (talk) 14:00, 25 February 2019 (UTC)

I am strongly against spamming "Avoid personal attacks or harassment." everywhere. It only insults people who would not be doing this anyway and people rude enough to harrass others will not stop just due to this warning. And it takes useful space on a talk page. (I am probably just against other parts of that template) Mateusz Konieczny (talk) 13:53, 25 February 2019 (UTC)

I am not, please stop it @Mateusz Konieczny:. I agree that Władysław Komorek might have been too fast and has not waited for others to reply long enough, but reverting does not help anyone. It is not like spam or copyright infringement where you have to act fast to avoid spreading. --Tigerfell  (Let's talk) 16:21, 25 February 2019 (UTC)

So what is the plan? Wait a bit and then delete them later if there is no support for adding them everywhere? I worry than at first it will be "I mass added them without discussion, but reverting is not acceptable - do not act rashly" and later it will turn into "why you protest, this templates are present for long". Despite that this is undiscussed and done without any real consultations despite large impact. Mateusz Konieczny (talk) 21:51, 25 February 2019 (UTC)

No, I would have preferred if you discussed this first even if it is a revert, because maybe our discussion would have concluded that on some pages the template is useful. It looks a bit weird if you do not contribute to the discussion at all, but then comment once and revert immediately. --Tigerfell  (Let's talk) 10:47, 26 February 2019 (UTC)

"If, after a few months," - sorry but it is completely absurd. After few months you will argue along lines "it is tradition, it stayed for months why you are protesting now" Mateusz Konieczny (talk) 21:58, 25 February 2019 (UTC)

This is obviously wrong, if you were referring to me. --Tigerfell  (Let's talk) 10:47, 26 February 2019 (UTC)

And please do not add google translate links everywhere - maybe someone is not aware of it, but are we really going to start linking all useful pages on the Internet on top of every single talk page Mateusz Konieczny (talk) 13:59, 25 February 2019 (UTC)

I would like to point out that templates {{Talk}} (since 2009) and {{GoogleTranslate}} (since 2008) are available on Category:Template:Internationalisation. Created for use on the Talk page.
Advanced users have the knowledge that "Click+ right mouse" opens a new, translated page. {{GoogleTranslate}} is the same, a convenience for people with unskilled knowledge.
There were never any objections to using them.

I have not noticed any discussion so far, that to use Wiki templates is necessary "Proposal", or admission, only after extensive discussion.
For this I noticed the following approach to the use of templates:
If, after a long time, there is no use, or there are any critical remarks about their use, someone writes the proposals for removal.
If not, they remain in use.
Please, also, pay attention to my first requests in this thread.
So I expect a wider discussion and new proposals to facilitate/simplify the reading/writing of Talk pages rather than editing wars started by Mateusz Konieczny.
After completing the broader discussion and formulating new rules/ideas regarding the above topics, I will personally remove all my extra editions.
BTW The added templates are informational templates, and information templates are commonly used on various Wiki pages, without any subjective omissions. --Władysław Komorek (talk) 19:05, 25 February 2019 (UTC)

Just because it is an old idea does not mean that it is a good idea. Nobody spotted this bad idea because there were not actually used Mateusz Konieczny (talk) 21:49, 25 February 2019 (UTC)

I see that you and others do not really understand whether I wrote.

I do not write about the translation of discussion pages but I wrote about the visualization of pages written in other languages.

1. How can a person from Brazil, Poland or Iran know what others have written on a topic that interests him, without knowing English?
   If he does not know, he starts a discussion again in his language group about problems already solved on other language sites. It is pointless. So we have no communication between thousands of Wiki users, and yet we have the 21st century.
   This reminds me of the state office with rooms where, in one of the rooms, for many months, it is discussed how to solve a problem, when in the next room, the problem was solved more than a year ago.
   But there is the lack of communication between them too.
   This is what discourages many valuable people.
   
2. Why should we have empty discussion pages, without Ambox or Templates? Is adding them prohibited or causing complications? No. This is only because a few people from a community of tens of thousands do not like them and do not want them, or block all innovations.
   
3. Why does everyone have to write in English when we have the opportunity to read each page of the discussion in our native language without a problem, with the current state of technology?

I have added several templates available and use on Wiki, for testing purposes (maybe they're better on the Wiki), to more popular pages in multilingual discussions to trigger a substantive discussion on the lack of communication between the Wiki discussion pages in different languages.

However, instead of substantive discussion, it began with reverts and denial of use, current, allowed templates.

The easiest way is to criticize, it is harder to present new proposals.

But "mass editions" are not related to the topic of this thread. You can create a separate thread on this topic.

What is the moral for new people in the Wiki? Do not try to change something, because, soon, a few people will change the discussion into "I like it and I do not like it"

I personally do not need these changes. I have started to change under the influence of many requests, written to me, from Polish users.

I would like to have: I click on the icon "Preview talk page in other languages" and I see the selection of namespace of Talk pages where there is some text. I click, for example, on "fr" and see the French page of the discussion in my language. --Władysław Komorek (talk) 11:06, 27 February 2019 (UTC)

BTW. I added {{Talk}} as a curiosity, but not as an important template in this topic. Also all {{Talk}} has beem removed from Talk pages. --Władysław Komorek (talk) 11:08, 27 February 2019 (UTC)

Proposed solution

MediaWiki has a special page MediaWiki:talkpageheader -- any content on that page will automatically show on every talk page. I have created an example that only works with the Talk:Data_items and any page that ends in .../talktest - in other words, if you go to Talk:Wiki/talktest, you will see the header (currently shows language bar and the talk template). Even if the talk page does not exist! We could customize what content is shown based on the title of the page (e.g. we could add some custom text for Key/Tag/Rel pages, plus some language-specific content as well). Note that the message will not be shown during the page editing - for that we will could use other MW messages like newarticletext, talkpagetext, etc. --Yurik (talk) 02:46, 26 February 2019 (UTC)

It is a good technical solution, but it is not solving two more serious problems - of large scale changes without checking whatever it is desirable and making sure that text applied everywhere is OK. Please, before applying any text there run a proper discussion - unlike what happened with mass adding {{talk}} template everywhere. Mateusz Konieczny (talk) 08:46, 26 February 2019 (UTC)

The whole idea of this solution is for the community to establish what we want to show on the talk pages, and gradually improve it. No talk pages are being changed for this. --Yurik (talk) 13:00, 26 February 2019 (UTC)

I am not sure if we need that on every page. I once heard there is an option to show something just in editing mode within the editing window?

It does not work for me. I tried editing and purging Talk:Data items as well as editing Talk:Wiki/talktext but I did not save them. --Tigerfell  (Let's talk) 10:47, 26 February 2019 (UTC)

@Tigerfell: do you see the language bar at the top of the Talk:Data_items (regular page, not editing)? Note that the language bar appears, even though it is not present in the wiki markup. As for editing a page, there are other MW messages that have not yet been created. You can see what messages are being used by adding ?uselang=qqx URL param. E.g. this talk page shows all of them. We could create MediaWiki:talkpagetext (shown when editing), and MediaWiki:newarticletext (shown for new pages only). And yes, lets figure out what needs to be shown and when. --Yurik (talk) 12:58, 26 February 2019 (UTC)

Your interface language needs to be en (I am using en-ca). Any chance we can implement a fallback also for the other languages with no translation for {{Talk}}? --Tigerfell  (Let's talk) 10:45, 27 February 2019 (UTC)

Using MediaWiki:talkpagetext and MediaWiki:newarticletext sounds reasonable to me. Then the majority of the pages would not be filled up. Seems that these pages were deleted once, but I cannot see by whom. Maybe there was a reason for that? Can you see that, Yurik? --Tigerfell  (Let's talk) 10:45, 27 February 2019 (UTC)

@Tigerfell: I think it was auto-deleted by mediawiki software itself during the version upgrade -- at some point in the past, messages were moved from UI to a special translation file, so when they were the same, they got deleted. --Yurik (talk) 01:04, 2 March 2019 (UTC)

I posted a question about translation issue in a ticket T217357, hopefully we will get an answer why it is not auto-falling back. I wouldn't want to add it to hundreds of pages, but obviously it is an option. --Yurik (talk) 01:04, 2 March 2019 (UTC)

Adding Templates and Ambox to Talk pages

We have a lot of templates designed for Talk pages.
therefore, the following questions are:
1. Is it allowed to use all available templates on the Talk pages? If not, which can we used and which can not be.
2. Is it necessary to have an earlier, extensive discussion, to use them?
3. If there are objections, should we not previously submit a given template for Delate proposal, or in the description of the template, add, the amount that will not be included in the "mass edition"?
4. Why do we add some templates to Wiki pages without any discussion, and we have to discuss adding them to the discussion pages?
5. Should there be a list of templates for Talk pages in which it will be given, how many times can a given template be used without discussing with others about their use?
6. Why is it not allowed to create the initial Talk page, only with the Template or Ambox, when the appropriate Wiki page already exists? Is it prohibited or complicates the correct operation of the Talk page?
7. Do we have pre-written rules for creating and maintaining Talk pages?
That's it so far. --Władysław Komorek (talk) 11:39, 27 February 2019 (UTC)

My opinion @Władysław Komorek:: You did a mass edit without discussing this properly, it is not about some templates. I personally do not have a problem with this particular edit, but I guess others want you to follow Automated Edits code of conduct when doing mass edits even in the wiki.

Regarding 6: Well, creating an "empty" talk page is confusing to users, because when you add a language bar to the other language versions, it shows that there is a discussion in the first language. Then you click on the link and find an empty page. If you would do that with all languages (about 80) in the template, it would be difficult to find those discussions that actually have some content. --Tigerfell  (Let's talk) 12:09, 27 February 2019 (UTC)

ad2 - yes, in case of mass adding them, ad4 - I would be equally unhappy about undiscussed mass adding new clutter to articles Mateusz Konieczny (talk) 17:37, 27 February 2019 (UTC)

@Mateusz Konieczny: It looks like you do not really understand the text in this thread.

If you need, I can write to you in Polish or on the Polish forum.

You're writing non-topic all the time. The thread is "Adding Templates and Ambox to Talk pages".

If you want to write about "mass adding", please create a separate thread. Although I wrote earlier on this topic, we can discuss this topic more widely, again, under a new thread. --Władysław Komorek (talk) 22:56, 27 February 2019 (UTC)

Are you seriously claiming that your method of adding templates to talk pages is offtopic in thread about adding this templates to talk pages? And note that I answered questions that you asked - so it is even less clear why you think that it is offtopic Mateusz Konieczny (talk) 09:34, 28 February 2019 (UTC)

Paternalistic talk template (harassment part)

See Template talk:Talk Mateusz Konieczny (talk) 22:01, 25 February 2019 (UTC)

Tag parameter cleanup

Now that {{Tag}} can automatically determine the language of the current page, we no longer need kl=<lang>, kl=<lang>, nor the language-specific ones like {{Pt:Tag}}. It is enough to just use {{Tag|key|value}}, and it will automatically link to the current language IF it exists, or to English otherwise, for both the key and the value. I only found one case when it was linking to a different language -- Key:design:ref links to RU:Key:design:code:SPb, which IMO should be fixed regardless. I have been running the bot to remove the kl:, vl:, and localized Tag templates. My next steps will be to import "seeAlso", "implies", "combinations", and "requires" into Data Items, but I am a bit worried of how mismatched those values are between languages. For example, take a look at tourism=hotel at taginfo -- items are substantially different. Should I just import EN, or should I add a list of all values with the limiter per language? It might get a bit scarry :) --Yurik (talk) 02:27, 2 March 2019 (UTC)

I would be careful with the parameter "requires" and "combinations". The English version is not always up to date. I noticed that, often, the German version is more understandable and more updated. Maybe additional information from the comparison of the last update date of different language versions would show something. --Władysław Komorek (talk) 09:33, 2 March 2019 (UTC)

Take care not to fill up Category:Pages with too many expensive parser function calls with pages that make an extra check for a tag page in the same language. --Andrew (talk) 08:06, 2 March 2019 (UTC)

@Wynndale: - it currently has 41 pages in it - have you seen a larger number before? BTW, I think the language bar is what causes most of the slowdown - because it checks for every single language page existence. Hopefully we will switch to a data-item driven approach, where it can simply use the data stored in the data item to draw the language bar. Do let me know if you see any slowdowns.

--Yurik (talk) 08:53, 2 March 2019 (UTC)

The language bar avoids most expensive calls by using red/blue switches and a special CSS style.--Andrew (talk) 09:58, 2 March 2019 (UTC)

We should do something with How to map a. It is too long, an incomplete page that practically nobody reads because it takes too long to open it. --Władysław Komorek (talk) 09:33, 2 March 2019 (UTC)

The page in English was redirected to a category for a while but someone recreated it.--Andrew (talk) 09:58, 2 March 2019 (UTC)

Hmm. Is it possible to have only the "alphabetic search" bar on this page (in all language versions), but only after clicking on a given letter, will we see the feature for the given letter? And to divide "How to map a" into pages: "How to map a/A", "How to map a/B", etc.

For example with the template {{Template:How to map a/Tabs}} --Władysław Komorek (talk) 14:21, 2 March 2019 (UTC)

I've tried to shorten the loading time and size of the Map Features page by creating a list of all of the Map feature pages, adding, by the way, missing pages and internationalizing them. It took me a long time, but it was probably worth it. --Władysław Komorek (talk) 19:35, 4 March 2019 (UTC)

If importing needs to be done I would just import en version (I treat other language version as possibly outdated and incorrect translations) Mateusz Konieczny (talk) 09:08, 2 March 2019 (UTC)

There looks like a problem at https://wiki.openstreetmap.org/w/index.php?title=FR:Key:usage&diff=1815433&oldid=1799324&rcid=&curid=156761 .--Andrew (talk) 08:46, 3 March 2019 (UTC)

@Wynndale: Thanks! I fixed a few of them already by hand, but apparently one slipped through. I will run a search later to make sure there are no other ones. --Yurik (talk) 17:55, 3 March 2019 (UTC)

Is there a "relation" template similar to Tag/Key ?

We have many relation pages, usually in the Relation:... format. Do we have a generic {{Rel}} template that links to those pages, similar to how we have an auto-translated {{Tag}}? Should it be implemented? Anyone wants to do it? :)
Possible visualization: {{Rel|route}} →  route (the link is always going to the same language as the current page) --Yurik (talk) 03:01, 4 March 2019 (UTC)

I think it is a very good idea. We do not use the Key/Tag:type=something format. This also solves a misunderstanding with the {{Tag|type}} tag. --Władysław Komorek (talk) 08:57, 4 March 2019 (UTC)

I produced some template. Feel free to change. --Tigerfell  (Let's talk) 22:57, 12 March 2019 (UTC)

@Tigerfell: thank you!!! I left a comment on the talk page. I guess we should discuss implementation there. --Yurik (talk) 23:06, 12 March 2019 (UTC)

When are we going to migrate to Translate extension?

I ask when, instead of if, because this was already decided here roughly 7 years ago and even a ticket has been opened and since then, nothing happened.

I'm bringing this up here on Talk:Wiki as suggested here.

The migration strategy was already mentioned in the main discussion.

Disclaimer: I do not really know how this Extension works or how to use it, since I never used it. I just think is going to ease the work of translators (myself included) by providing all of the nice statistics and not having to verify paragraph by paragraph what is with an outdated translation. Besides that I'm willing to help with the migration :) --Dhiegov (talk) 14:25, 6 March 2019 (UTC)

I could take a look after I made MultiMaps extension available for our wiki (discussed in #Map extensions). I am moving along the task list outlined at GitHub issue 252 in November, currently waiting for review of my patch to the extension at Wikimedia Gerrit (so I can not influence how long it will take).

However, I can not promise anything. There might be some technical issues that I can neither cope with nor know now.

Seems to be quite a radical change to me like changing the page titles. Do the others still want this feature added as they did in the past? --Tigerfell  (Let's talk) 23:47, 7 March 2019 (UTC)

"changing the page titles" what kind of changes are expected? From quick look I see no summery anywhere. Mateusz Konieczny (talk) 08:06, 8 March 2019 (UTC)

https://www.mediawiki.org/wiki/Extension:Translate/Mass_migration_tools#The_approach seems to outline the steps necessary. Looks like there is a tool. But I guess we do not need to use the translation extension on all pages. --Tigerfell  (Let's talk) 09:36, 8 March 2019 (UTC)

"roughly 7 years ago" - I would not assume that it still wanted Mateusz Konieczny (talk) 08:06, 8 March 2019 (UTC)

Okay, anyone speaking up? (You can find the documentation at https://www.mediawiki.org/wiki/Extension:Translate.) --Tigerfell  (Let's talk) 09:36, 8 March 2019 (UTC)

I'm a bit on the fence about this one. On one hand, it would be far better to have a well defined interface for translating content - essentially treating wiki page as being a list of translatable messages (paragraphs), and anyone being able to go into a "translation" interface, view each paragraph individually, and translate it. Any links and other content on that page would be treated as "special values", so a tag template will stay the same in all languages. If the page paragraph is updated, translators will see which paragraph has changed and update it accordingly. Any untranslated text will still show up as English. On the other hand, working with such text (all the <-- T99 --&rt; messages) are very brittle, and the visual editor does not handle them correctly last time I checked. So editing EN wiki (the "core" content) will become far more difficult. Plus I am not exactly sure how we will migrate from the existing system to the translation system. --Yurik (talk)

I feel similarly. I definitely see some challenges with translations that would be greatly helped by proper tool support: Being able to judge the completeness of a translation, and being able to identify outdated translations easily. The latter, in particular, feels like a major problem at the moment. People are often eager to create translations, but do not keep them in sync with the original, which leads to outdated pages and diverging tagging practices between language communities.

Unfortunately, the main downsides of the extension still exist 7 years later, especially the requirement to clutter the English text with various markers that make wiki editing less accessible to non-technical editors. The documentation for the extension writes that "[i]t adds a bit of overhead to the pages that need translation, but the benefits far outweigh this." I think this assessment may ultimately be too charitable: When I look at the source code for this simple list from their own docs, I feel that this mess might just not be worth it despite our very real problems with localization. --Tordanik 23:04, 8 March 2019 (UTC)

Do the <translate>...</translate> tags are put by humans or is it an automated process by the extension software? If put by humans, that list could be joined in a single translation unit, which would make it a little more readable, although simplifying a bit the outdated translation feature, since what could be a change in a single item of this list would show as a change in the entire list, though that's not really a big deal, since you can see what differed from the last edit, then update it accordingly.

A new issue using this extension I saw was in regards to the translated page independency in relation of the source (untranslated) page. There's none of that when using this extension, as I inferred from the second paragraph of this heading in their docs. How can we further localize pages, by adding special info that just makes sense for the speakers of the localized page's language, like the second paragraph of this key, which was localized into the first paragraph of the version in portuguese?

Regarding the outdated translations issue we have here, I've got an idea: We have {{Translated}} already established and it informs the last time someone checked the source (untranslated) article to see if it was changed and updated the translated one. Could we make a form of getting this date data (that could be unreasonable, since the template does not establish a fixed format for the revisiondate parameter), or maybe the date of the commit this template was added (we maybe could use tags on commits like wikipedia does to maybe biased commits, but to mark what commit was a translation check), and, from this date until now, show in an easy way if there are major changes to the page? (or we could simply have the translators get the major changes to the page, like we have right now, but I don't think that's a documented technique (maybe its so obvious it doesn't need to be)). The translator would then view the diff since the page was checked until now and then update the translation accordingly. That's a very manual process, but deals with the cluttering problem, the extra logistic of migrating all translations to this extension and the independence problem stated in the paragraph above. --Dhiegov (talk) 01:40, 10 March 2019 (UTC)

Based on my experience (Data items, Develop, Proposal process, ...), I think working with diffs is pretty impractical as it tends to take a long time to find the changes because diff sometimes fails when longer paragraphs were inserted showing massive deletions instead. I also miss an easy feature to mark a translation of the major text as irrelevant for translation (yes, I could manually update the timestamp in your approach).

We also have {{Translation out of sync}} and others inserted by humans. I found them sometimes misleading (like someone missed information in general and inserted them like they are "out of sync with reality" or not removed after updates).

I would appreciate if the localisations would be translated as well. Many mappers also map in other countries. I would simply append the source text. We would also not need to apply this translation feature to all pages. I could imagine totally different main pages for instance.

From a technical POV, I guess we would suffer some problems with Chef again. It looks like we need some composer features which might not work with the current configuration setup, so an installation would be a bit tricky I guess (but without really knowing the details). --Tigerfell  (Let's talk) 13:50, 10 March 2019 (UTC)

"clutter the English text with various markers" - sorry, but that is unacceptable and no go. I am quite technical person and templated mediawiki is for me harder to edit than source code of programs. Adding even more syntax into it will further reduce pool of people able to edit pages. Mateusz Konieczny (talk) 12:48, 11 March 2019 (UTC)

Looks like are not favouring this. I guess I will be using {{Translated}} then... --Tigerfell  (Let's talk) 11:21, 12 March 2019 (UTC)

Since it does not look like we want to have this implemented, I closed the related Trac ticket now. --Tigerfell  (Let's talk) 20:53, 11 April 2019 (UTC)

"incompatible with" added to the Tag infobox

Per @Fanfouer: request I added incompatible with (P44) to the data items and the {{KeyDescription}} and {{ValueDescription}} templates. You can see it in action for power=generator (Q4990) -- see it visualized in Tag:power=generator (automatic in all languages). This change paves the way for us to start copying other list-like parameters (implies, seealso, ...). Let me know if you notice any breakage. To add this property to any other item -- scroll to the bottom of the data item, click "add statement", type P44 in property, and add any number of keys or tags. --Yurik (talk) 02:32, 7 March 2019 (UTC)

Page creations about Romania and Moldova

I would like to bring up the page creations of Lightcyphers. The company has so far created about 2000 wiki pages about all kinds of details about these two countries. I personally have three concerns about this:

• The pages are not used for editing (few changes only).
• The amount of pages hides potentially relevant information (like which pages are actually used by a local community and which pages contain more than a simple template).
• This comes close to some sort of slow-motion automated edit which I see not adequately discussed (or at least announced).

I contacted them in November 2018 and documented their responses on the user talk page of the executing account Special:Permanentlink/1702636. I was basically told that these pages will be used for communication with the local community. Some months later, you can see that about half of the oldest pages still have not changed yet. The others were basically edited by just some combination of the users @Lightcyphers:, @Anatolie:, and @Hero: (I did not check every case).

I have the feeling that this is going the wrong way. What do you think? --Tigerfell  (Let's talk) 15:04, 7 March 2019 (UTC)

--Anatolie  First I'll address concerns:

* We are adding extra info on top of each "page from template" as soon as we finish a task (For example finishing audit of streets in a municipality). Usually it takes a lot of time ~1 month for a city with 800-1500 streets.

* The local community is very poor in both countries. So main scope to create so many pages, is to find local leaders and build up this community. Also we would like to give new comers a standardized baseline where they can add information. Another trick is that we contact every local government authority in these countries and use wiki as a "CRM" to document pieces of information we get from them. Of course we can deploy our own Mediawiki but this will result in fragmentation and in one day all this information can be lost.

* Regarding Automated edits it's in fact it happens reverse order. We start in automatic fashion, but after each page is maintained very manually, depending on pieces of information we are getting.

Organised Editing is a new phenomena on OSM. But as organized team we have somehow to plan and document our activities. We are not as fast as we would like to be. The time-frame from November to March isn't long for us. Our agenda is planned for years of edits. We have to do a lot of edits with very limited team and dead community. Also we have somehow to re-kickoff new local communities. Maybe you'll suggest to make pages "as they come" in our edits activities. We analyzed such scenario but creating pages in front is easier for us and we don't plan to abandon them as I mentioned in November.

* Calling our page creation automatic is unfair. For pages of Romanian authorities we collected manually some information like web pages with potential source of data to enrich standard templates. We had extracted OSM ID's manually and invested a lot of effort in what you call automatic edits.

* We have to manage somehow our communication with thousands of local government actors and collect pieces of data regarding street names and addresses. There is no way to collect this data from the ground because in villages there are no plates on buildings.

* In case of Romania the wiki was dead for many years and we try restart this tool as community convergence point. We had not created pages for villages in Romania, just towns and cities we plan to review and improve.

* In case of Moldova we had finished every single town, and we have ambition to map all villages and involve local regional activists to coordinate their actions on wiki.

"each page is maintained very manually" - similar pages were created for some other countries. All examples known to me are inactive or ended deleted as useless. Overall, this is likely a well-intentioned but useless effort. Have you considered spending that time on mapping or organizing mapping party? Maybe I am missing something but creating hundreds of wiki pages will not create community and would not be used by it. Mateusz Konieczny (talk) 14:00, 8 March 2019 (UTC)

"will be used for communication with the local community" - this is ridiculous, even large communities have no more than mailing list, forum and IRC or IRC clone like slack or discord. There is no OSM community that is so large that hundreds of separate channels/pages are necessary due to large volume Mateusz Konieczny (talk) 14:02, 8 March 2019 (UTC)

My plan is to use link to wiki for sharing on places where "locals" meet online. Like facebook groups or other social networks. So it's not community in large sense of the word. Anatolie 

I would suggest that you build a community at one city first and see how the wiki page works. See, there are probably some hundreds of pages about Brazilian cities and municipalities at Category:Cities in Brazil (at least three levels of subcategories to this). This was a comparable incident. I checked some pages and they were not used either (please correct me @Ftrebien: if I am wrong). At least 90 pages are deleted again (Log). Another experience originates from the community of Germany which created a lot of pages for coordination first and then figured out that this did not help them (they wanted to update the map and not the wiki about the mapping progress). Some pages are still used but mostly for specific topics (public transportation, automated error reports, ...).

Please, let us not repeat that. --Tigerfell  (Let's talk) 12:56, 10 March 2019 (UTC)

Adding edit summaries to the data item edits

Following this conversation, it is possible to add user comment to the data item edits, but the current implementation shows the edit box at the very top of the screen - not very convenient, and it shouldn't be the same comment for all edits made on a single page. Would any javascript developers be interested in improving the UI a bit? To get started, copy the editsummary code (last) from User:Yurik/common.js to your common.js, and use sandbox (Q2761) for experiments. --Yurik (talk) 23:47, 8 March 2019 (UTC)

-- enable it in your preferences, on the Gadgets tab. --Yurik (talk) 21:57, 16 March 2019 (UTC)

Proposal: new namespace for tagging proposals

The proposal process currently requires creating a page under the "Proposed features" pseudo-namespace. I'm proposing that we move all the pages that begin with "Proposed features" to a new Proposal: namespace and create the pages there from now on.

The discussion in "Criteria for deleting proposal pages" raises the point that abandoned, rejected, and draft proposals end up cluttering search results on this wiki, sometimes burying actual approved tags under rejected proposals. Some users have expressed a preference for blanking or deleting inactive proposals, while others would like to keep them as part of a historical record. In general, I would prefer to archive but preserve inactive proposals that have meaningful content. Sites like Wikipedia have vast archives of discussions in their project namespaces, yet these archives don't create problems for readers trying to find actual content. Still, I'm sensitive to the desire for cleaner search results and better discoverability for things that have gained consensus.

By default, Special:Search searches in the main namespace only. (For whatever reason, Tag:, Key:, and Relation: are only pseudo-namespaces, not real namespaces, so they also get searched by default.) Clicking the "Everything" or "Advanced" option searches in more namespaces. By moving proposal pages to a Proposal: namespace, we can ensure that users only see proposal pages when they're specifically looking for them or when they're trying to perform a broader, more advanced search.

The namespaces are defined in MediaWiki configuration files, so if there's consensus to create the Proposal: namespace, a sysadmin would need to be involved in making the change. Then we can use a bot to mass-rename the proposal pages. (I'd personally prefer renaming them en masse, but gradually phasing in the new namespace is also a possibility.) Though many pages would be affected, I view this as a small step that solves a usability problem without necessarily blocking more significant proposals such as Yurik's.

 – Minh Nguyễn ^💬 22:53, 12 March 2019 (UTC)

I think proposals should be searched by default just like tags - in many cases they are the only documentation of tags. What could be done is to selectively move some proposals into a different namespace.. if they are useless for anything but historic purposes. Also, wondering if the default search engine could be made to prioritize "more established" documentation over stuff like abandoned proposals? RicoZ (talk) 19:37, 15 March 2019 (UTC)

Personally, I think this would be a good idea and address a lot of the issues with proposals cluttering things up. Making the default search engine prioritize more established documentation if possible is a good idea also. Although I don't see them as mutually exclusive. Both would be improvements. --Adamant1 (talk) 01:09, 16 March 2019 (UTC)

@RicoZ: The problem I'd like to address is that proposals intermingle with more authoritative results when they're searched by default. I think it'd be fine if users have to click "Everything" or check "Proposal" to find proposals, compared to having to click "(next 20)" to find an actual tag page in their language. Namespaces are a pretty reliable way to ensure that people can use the Special:Search options to decide whether to search proposals. Otherwise, they have to accept the defaults or use more less memorable syntax like -prefix:"Proposed features" in their queries.

That said, your response reminds me that CirrusSearch does offer a way to boost pages containing certain templates. I don't think that mechanism would let us demote proposals containing {{Proposal Page}}, but I guess we could use it to promote tag and key pages containing {{KeyDescription}}.

 – Minh Nguyễn ^💬 05:24, 17 March 2019 (UTC)

The template boosting looks very interesting. Wondering, could we have a template like {{Old useless page}} and the setting 'File:boost-templates:"Template:old useless page|10%" ' would take care that it would come pretty much last in the search? Another idea, could the search return the main search and clickable links like "50 results in proposals", 120 results in talk pages" etc? RicoZ (talk) 21:26, 21 March 2019 (UTC)

@RicoZ: It isn't straightforward to add clickable links like "50 results in proposals"; that's what the namespace checkboxes are all about. But boosting {{Proposal Page}} by 50% (which is apparently a negative boost) seems to have decent results: dance school versus dance school boost-templates:"Template:Proposal Page|50%". We could apply something similar for templates such as {{Historic artifact start}}, but I think just this one rule already gets good enough results that we should apply it by default. – Minh Nguyễn ^💬 22:59, 23 March 2019 (UTC)

That looks good to me. It doesn't seem easily possible to differentiate between proposals in various stages, like giving a lower weight to abandoned and rejected ones? Are there any other "SEO hints".. I was wondering if the search engine does take into account the number of links pointing at something? RicoZ (talk) 21:47, 25 March 2019 (UTC)

We could have {{Proposal Page}} include a trivial or no-op template that makes the status clearer for the boosting mechanism. I don't think there's a straightforward way to account for inbound links, though. – Minh Nguyễn ^💬 19:29, 26 March 2019 (UTC)

I think this would be a great improvement. Somewhat surprised that the search engine won't do any "page rank" calculation but that is a different subject. RicoZ (talk) 22:27, 28 March 2019 (UTC)

While this might be a good idea, this seems not completely thought through to me. "Key:" and "Tag:" are not real name spaces, because name spaces were created for the languages. So if you have a page like RU:Tag:place=city, it is already in the "RU" name space. If you propose to change that, you would also need to address the issue of the languages and their inconsistent configuration. --Tigerfell  (Let's talk) 12:02, 16 March 2019 (UTC)

Maybe, I sound a bit negative given that I even like this suggestion ... I just wanted to make the point that we would need to decide on the future of our language namespaces DE, ES, FR, IT, JA, NL, and RU (+ talk namespaces each) as well. Is there any reason to keep them other than avoiding mass changes and keeping compatibility for the relevant templates? --Tigerfell  (Let's talk) 13:55, 16 March 2019 (UTC)

@Tigerfell: I'm not proposing to touch the language namespaces. Virtually all proposals are in English and will likely continue to be in English for practical reasons, so it isn't a problem that the Proposal: namespace would be exclusive of the language namespaces. For what it's worth, I've always understood the language namespaces to be a historical artifact. They're already configured to appear in search results by default, just like pseudo-namespaces like Fi: and Vi:. – Minh Nguyễn ^💬 05:24, 17 March 2019 (UTC)

The problem is this "virtually". I know of at least three cases where proposals are not in English (two of them do not even have an English counterpart). I am afraid there is a need to address this.

I think it would we worth reviewing this historic decision and possibly change it once, but oh well.... ..... --Tigerfell  (Let's talk) 15:25, 17 March 2019 (UTC)

@Tigerfell: I found a couple examples of what you're referring to: Uk:Вікіпроект Україна/Класифікація доріг (голосування), RU:ВикиПроект Россия/Голосования/Правила написания номеров домов (and an oddball, Japan tagging/Access transportation mode). These examples seem to be about country-specific interpretations of existing tagging schemes. As much as I want to counter Anglocentrism with multilingualism, I'm curious how a globally relevant proposal could even get through the proposal process, practically speaking, if it isn't in the same language as the vast majority of proposals here. But if non-English proposals are something we want to promote in the future, then the Proposal: namespace could accommodate "/xy" suffixes instead of language-specific (pseudo-)namespaces. Multilingual Wikimedia wikis such as Meta-Wiki and Commons always suffix page titles for translations, due to the expectation that every page can be translated into a large number of languages. Language suffixes in Proposal: wouldn't be a difficult special case to add to {{Languages}}. – Minh Nguyễn ^💬 18:44, 17 March 2019 (UTC)

I think it is not up to us to decide on promoting specific languages. We already have these proposals. We currently use prefixes for all languages including categories and templates (see Category:JA:日本 for instance). But then you will run into the problem of inconsistent capitalisation (compare Pt and ES), which is why I suggested to remove those language namespaces. Maybe renaming is sufficient? --Tigerfell  (Let's talk) 20:04, 17 March 2019 (UTC)

@Tigerfell: I'm not opposed to removing the existing language namespaces, but I think that we should couple that change with the introduction of language suffixes, which works with Special:MyLanguage. (For example, Special:MyLanguage/Map Features would automatically send users to Map Features/de, Map Features/es, etc. based on their interface language.) Moreover, I think that would be a big enough change on its own that it should be a separate proposal, maybe one that could be completed before the Proposal: namespace is created. – Minh Nguyễn ^💬 23:02, 23 March 2019 (UTC)

I appreciate that. I always thought that you need Translate extension for Special:MyLanguage to work. Can you still filter for a specific language in the search results then? (I guess this was the sole reason for language name spaces.) --Tigerfell  (Let's talk) 23:20, 23 March 2019 (UTC)

MyLanguage used to require the Translate extension but got folded into MediaWiki core at some point. Unfortunately, there isn't a built-in UI for selecting a subpage name or suffix. But we could extend MediaWiki:Search-summary or MediaWiki:Searchmenu-new to provide links that add additional criteria like incategory:Categories/ja. (A built-in inlanguage: operator would require the Translate extension.) – Minh Nguyễn ^💬 00:55, 24 March 2019 (UTC)

@Minh Nguyen: There are cases where national community do have proposals for specific mapping/tagging guidelines which should intentionally apply in their country only. For example, the German community discussed about a guideline for landuse clued to roads and voted on proposals about the usage of multipolygons, associatedStreet relations and (soon) about street relations. Some proposals are hold at talk pages which is not a optimal place for them. The current status works quite well with proposals in languages other than English. If we move proposals to a special namespace, people will either write a German proposal on a page called Proposed_Features:Verkleben_von_Landnutzungsflächen_mit_Straßen although it is not English. I am sure that a gardener would feel the need to move that page into the German namespace. --Nakaner (talk) 23:24, 17 April 2019 (UTC)

Examples for Germamn proposals: Talk:Relation:associatedStreet#Deprecation_of_associatedStreet_in_Germany, User:Frederik_Ramm/Flächenverklebung (currently in user namespace), DE:Proposed_features/Empfehlung_zur_Verwendung_von_Multipolygonen --Nakaner (talk) 23:30, 17 April 2019 (UTC)

Thanks for the explanation and these examples Nakaner. Given that it would be impractical to have a namespace for each language or national community, I really think we should consider deprecating language namespaces in favor of making the remaining namespaces multilingual, using language suffixes and Special:MyLanguage in cases where a page has multiple translations. I think a lot less gardening would be required that way. But that's a much more invasive change that would affect the entire wiki, not just feature proposals, so it'll require more thought. – Minh Nguyễn ^💬 05:20, 19 April 2019 (UTC)

Being able to search proposals easily is an advantage, not a disadvantage. If the issue is that people might understand a proposal page as a normal documentary page, we should modifiy the presets used for draft and abandoned proposals and make them show an Ambox or other kind of warning. There are quite a few tags which are still documented in proposals only and there is no requirement in OSM to vote on a proposal before others use the tag. --Nakaner (talk) 23:30, 17 April 2019 (UTC)

I'm not at all against easily searching for proposals. With the proposed namespace, proposals would still be one step away, by checking "Proposal" in the list of namespaces on Special:Search or prepending the query with proposal:. Even without that namespace, the boost templates mentioned above would ensure that well-established tags get more prominence over proposals in a default search. I think that makes sense given the primary reason people come to the wiki, which is to discover well-established tags they can feel confident in using. – Minh Nguyễn ^💬 05:20, 19 April 2019 (UTC)

If you haven't done that yet, I would like to remind those in favour of the change to consult the Tagging or Talk mailing list because the proposals are discussed on the mailing list a lot. This is a discussion page on the wiki which is read by a small number of people only. The main place for discussions are the mailing lists and (in some countries) the forum. --Nakaner (talk) 23:33, 17 April 2019 (UTC)

I second @Nakaner: -- I really feel the proposals should be made as regular key/tag pages, but with a giant warning at the top that explains that this is not a recommended way of doing things, and if you see such tags in OSM data, don't consider them to be stable, but instead read the corresponding talk page to discuss it. There are very few proposals out there that are not centered around a single key. In those cases we can keep using the dedicated proposal pages, but otherwise they just add to the clutter.

BTW, per wiki documentation, "incategory:..." allows category search, so it would be very easy to only search proposals, or to exclude all proposals, but that requires Elasticsearch to be enabled on OSM wiki. --Yurik (talk) 03:53, 18 April 2019 (UTC)

@Yurik: We do have Elasticsearch BTW (version 5.6.16). --Tigerfell  (Let's talk) 20:24, 18 April 2019 (UTC)

@Tigerfell: good catch, i mistyped when i tried it myself, and thought it didn't work. So yes, @Minh Nguyen:, we can easily search for anything in a specific category (or when something has multiple categories) by simply using incategory:"category name" in the search box. Thus, it is enough for the infobox template to auto-add a category whenever it sees "status=proposed", and we are done :) --Yurik (talk) 21:09, 18 April 2019 (UTC)

@Yurik: That solves the problem of searching for proposals, but users currently have no problem finding proposals – they almost always show up when you aren't even looking for them. I don't think we should expect users to remember to add -incategory:"Proposed features" every time they search for something. Whether we keep the status quo, move everything to a proposal namespace, or move proposals onto specially marked tag pages, the boost template proposed above will mitigate the issue of too-prominent proposals as long as people use the wiki's built-in search engine. However, for those using a Web search engine like Google, the most effective way to avoid poor results would be to put things in true namespaces. – Minh Nguyễn ^💬 05:20, 19 April 2019 (UTC)

---

I guess the discussion (including the posts on the mailing list) turned out positively towards creating the namespace and configuring a decreased search rank for proposals, but then nothing happened, right?
More precisely: Would anyone object if I request the new namespace and then move the pages automatically to their new names? No links would break, because they will redirect to the new page names. --Tigerfell  (Let's talk) 20:24, 14 August 2019 (UTC)

Bring syntax highlighting to this wiki!

MediaWiki has an extension (now default on Wikipedia) which allows for syntax highlighting of wikitext, which makes it so much easier! Please consider bringing it to this wiki. Pizzaiolo (talk) 01:19, 29 March 2019 (UTC)

It is installed already. We also have a small intro at Wiki Help#Include source code. --Tigerfell  (Let's talk) 12:54, 29 March 2019 (UTC)

Is it possible to enable it in the preferences? I couldn't find any settings like that. Note that the syntax highlighting I'm referring to is not for source code, it's for wikitext, when editing the wiki. Pizzaiolo (talk) 01:24, 31 March 2019 (UTC)

I guess you either refer to CodeMirror extension (the one by Wikipedia) or Syntax highlighter gadget (the one you can enable). Which one do you mean? --Tigerfell  (Let's talk) 12:29, 31 March 2019 (UTC)

Sorry for the confusion, I meant the CodeMirror extension. Pizzaiolo (talk) 14:05, 31 March 2019 (UTC)

Personally, I am neutral in this. I am used to the current situation and I would have to switch off the highlighting in order to see the spell check. I guess there is some benefit but I can not really value it now.

In addition, when you proposed it on openstreetmap/chef/issues/231 ^GitHub, the system admins requested a wiki admin to backup the request. I guess they want to make sure there is some benefit for the wiki and a community consensus given that there were quite a lot of requests in the last months. --Tigerfell  (Let's talk) 22:02, 1 April 2019 (UTC)

I was asked to advise in this case and I thought it might be a useful feature for some people and the others can leave it turned off, so now it is present. --Tigerfell  (Let's talk) 21:56, 6 May 2019 (UTC)

Last call for discussing draft of deletion policy

There is a draft of a deletion policy for the OpenStreetMap wiki which is almost ready for voting. You can find it here: User:Tigerfell/Crafting (page will be moved shortly but the link will still function).

This is a last call for comments on this draft. Otherwise, I plan to start the voting on 7 April 2019 during lunchtime (UTC). Please observe that I will be rather busy until then, so I will respond slowly (also the reason I keep this on hold for now). --Tigerfell  (Let's talk) 00:08, 2 April 2019 (UTC)

The policy is now ready for voting -> OpenStreetMap:Deletion policy --Tigerfell  (Let's talk) 11:32, 13 April 2019 (UTC)

Info-boxes now share seeAlso, implies, requires, and combination params

The `seeAlso`, `implies`, `requires`, and `combination` parameters are now shared between all languages via the data items. A bot collects all key/tag values from those parameters from all languages, and adds them to the data items. A wiki page infobox will show all those values, unless the page has something else. We may want to start removing them from non-English pages (thus TagInfo will continue loading them, but we won't duplicate info). --Yurik (talk) 20:38, 6 April 2019 (UTC)

I'm a bit concerned that this might cause content from poorly-maintained translated pages to make its way to the other languages. (Case in point, the implies for building=office from the Polish page.) It could, of course, also be an opportunity to improve those translated pages! However, that would require people to actually notice the change. Is there a way to be notified of changes to data items corresponding to pages on my watchlist (without adding all of them manually)? --Tordanik 09:18, 7 April 2019 (UTC)

IMO the bot shouldn't remove anything, wheather from English nor from non-English wiki pages. Non-English wiki pages are not always worse than English ones. The so-called infobox should clearly indicate / distinuish if a value comes from the wiki page or from the data item page and if there is a conflict between these pages. Conflicts between different languages have to be resolved manually and not by a bot because sometimes a discussion is necessary and because what is in the infobox has to be kept consistent with the text (explanations) on the wiki page. On most wiki pages we have sections titled "See also" and similar. Currently on the data item page the bot has mixed all the parameter values from all different languages together. Isn't it possible that he adds qualifiers if values are only used in certain languages? Then these values could be not shown or shown in a differnt style on pages of other languages. --Hufkratzer (talk) 13:11, 7 April 2019 (UTC)

@Tordanik: the "simplest" way to watch all needed data items is to create a SPARQL query in Sophox to convert your list of key and tag IDs into data item IDs, and then using "edit raw watchilst" to add them. Clearly not the most straightforward path for most users, but we cold improve it by creating a simple tool to create that list automatically, e.g. by putting it on ObservableHQ (basically write some javascript to create a query for Sophox and to format the results).

@Hufkratzer: thanks for raising the office issue - it was already fixed by @Władysław Komorek:. I agree that a bot should not resolve these types of issues. Bot should only flag them, and let people resolve them. The current situation with every language having an (often outdated) copy obviously needs fixing. Google translate does good enough job of making it understandable, but usually that's not enough to help with fixing the content outside of the infoboxes. Qualifiers offer a very complicated route for multi-valued parameters -- e.g. if a value is listed in FR, but not listed anywhere else, it would have "limited to FR", but if there are 10 values, and they are listed in 20 languages except FR, which only has 1 value, you would need to add "limited to" to all 20 languages for all 9 values, or use "except in" -- this would be extremely messy and unreadable. I could generate a table of discrepancies that we can try to fix quickly, thus bringing all languages to the same values - would that work? Note that in most cases, the issue is not showing up because template parameters override whatever data is in the data items. --Yurik (talk) 17:47, 7 April 2019 (UTC)

First batch of possible errors: query (click play) -- combination containing the same values as required. --Yurik (talk) 21:05, 7 April 2019 (UTC)

I want to again express that I strongly disagree with showing in infobox something not specified at the wiki page (with sole exception of taginfo statistics). Mateusz Konieczny (talk) 18:38, 15 April 2019 (UTC)

Which wiki page? English? German? Polish? Does it mean that if I speak Polish but not English, and I live in NYC, I can map according to Polish wiki? How about Switzerland which has 4 official languages - which language rules should I adhere to? We have a fundamental problem of mismatched data. Data items are designed to solve exactly that. The transition to them did not create a new problem, it highlighted the errors we already have, so that we can now fix them. We finally have a way to keep things the same on all the different languages. Also, we now have a way to highlight REGIONAL (not lingistic) differences -- where we specify that certain things should differ depending on where you are. For example, a phone booth should show a different image depending on the location, not the language (there is an iD issue created about that recently). --Yurik (talk) 19:56, 15 April 2019 (UTC)

Showing the data from the Data items in the info boxes directly avoids conflicts between infoboxes of different languages but not conflicts between wiki pages of different languages and not between the info box and the wiki page of the same language. With your system if, for example, I add some "requires=..." this will immediately show up on Chinese and Japanese wiki pages that I can't read and/or adapt. So it is not unlikely that I will create conflicts between infoboxes and wiki pages without anyone is even informed about that immediately. I doubt that such a system is desirable and that there is no better solution possible. The list that you produced is nice but you can not expect that many people go through all kinds of lists all the time and repair new upcoming conflicts. --Hufkratzer (talk) 20:49, 15 April 2019 (UTC)

It is certainly not welcomed on English pages. It may be wanted on some translations but I am dubious about it Mateusz Konieczny (talk) 10:14, 16 April 2019 (UTC)

@Mateusz Konieczny: I think that was a reference to this proposal, which was prompted by a somewhat mistaken request on the iD issue tracker. I don't see the harm in allowing data consumers to associate tags with more locally relevant images, but none of that would affect the tag description wiki pages anyways. – Minh Nguyễn ^💬 05:42, 19 April 2019 (UTC)

Hufkratzer, you are correct - it does not solve the potential conflict between the infoboxes and the actual wiki page content. But the primary conflict we try to avoid is not between infobox and text, but between OSM data and wiki. So if you add a "requires=", it means this is the rule for all of OSM, and the more places reflect that, the better. The reality is that in 90% of the cases, the wiki content is simply outdated because there is simply not enough volunteers in that language to update it. Given a choice of having up-to-date infobox, or having everything outdated, I think users would prefer to have at least the infobox having accurate information (we could even add a small text underneath the infobox to indicate this -- making this whole argument moot). In theory, it would have been great to keep everything up to date, but it simply doesn't happen, so this is the next best thing. Plus, observing this discrepancy makes people aware of the problem. Additionally, we could offer people to add the data item to their watchlist when they edit a wiki page, so they are aware when thing change (some sort of an extra gadget?) --Yurik (talk) 21:09, 15 April 2019 (UTC)

@Yurik: Wikipedia has a preference to have the watchlist show edits to Wikidata items as if they were edits to the linked content page. Do you know what it would take to add a similar option on this wiki? – Minh Nguyễn ^💬 05:42, 19 April 2019 (UTC)

@Mateusz Konieczny: My understanding is that the infobox would transclude the content of another wiki page (the data item), just as some wiki pages already transclude large tables etc. from templates. Is your concern that people would find it more difficult to edit this information, that they would have to edit it in multiple places, or something else? Is the issue something that we can mitigate through better template design? – Minh Nguyễn ^💬 05:42, 19 April 2019 (UTC)

I oppose entire switch to storing data like Wikidata. Given that at this moment rolling back it is not feasible (and maybe it will turn out to be a good idea) I am trying to limit damage caused by it. Hopefully efforts of people attempting to improve OSM Wiki by deploying Wikidata-like thing and efforts of people attempting to improve OSM Wiki by opposing it will mostly result in a good things (some energy will be unfortunately wasted, but it also allows to limit some types of problems) Mateusz Konieczny (talk) 13:16, 19 April 2019 (UTC)

Renaming the project name space

I recently realised that your project name space named "OpenStreetMap" might be a bit misleading. This name space is intended for organisational content of this wiki and the user interface links to such pages. So, I propose to rename it to Wiki. The interface would then link to Wiki:VisualEditor instead of OpenStreetMap:VisualEditor. AFAIK this is merely an organisational question, because the existing pages would not change. This would also affect the associated talk page name space.

• current pages and redirects in this name space
• current pages and redirects in the talk page name space

I suggest to move wiki-related pages after renaming the name space and keep the other pages and redirects unchanged. --Tigerfell  (Let's talk) 22:25, 18 April 2019 (UTC)

Good idea, this has been bugging me too. The canonical name of the namespace is "Project"; all that would change is the localized name. I'm pretty sure changing the localized name would update the display name of each existing OpenStreetMap: page without actually moving it anywhere (in the sense of creating a log entry). So the only noise it would create on people's watchlists would be due to moving main-namespace pages to the project namespace. For what it's worth, a namespace can contain a space, e.g. "OpenStreetMap Wiki", but some templates may have to be adjusted to deal with {{NAMESPACE}} returning "OpenStreetMap Wiki" while {{NAMESPACEE}} returns "OpenStreetMap_Wiki". – Minh Nguyễn ^💬 05:30, 19 April 2019 (UTC)

There aren't any pages with the prefix Wiki:, because that is currently an interwiki link to some other webspace. I guess we would need to remove that first. This interwiki link has not been used, except for wondering why it exists. I would also prefer Wiki over OpenStreetMap Wiki, because it is shorter and there would be no need to adjust the template. Maybe, we should keep OpenStreetMap as an alias name to avoid breaking links. --Tigerfell  (Let's talk) 09:46, 19 April 2019 (UTC)

Oh, I forgot about that interwiki prefix. This particular prefix comes with MediaWiki by default. Adding a prefix requires a manual SQL statement; not sure if it's even that simple to remove one. There are a few direct links to WikiWiki, but it probably wouldn't be a big deal to remove the prefix if it's feasible to do so. Other naming possibilities include "OSM Wiki", "Meta", and "Project". – Minh Nguyễn ^💬 16:08, 19 April 2019 (UTC)

We have w:mw:Extension:Interwiki, so you can see the interwiki links at Special:Interwiki. Unfortunately, no one has the right to modify them there. I will file an issue for that. Should we have a vote on the name? I do not mind the name that much, it just should not confuse people. --Tigerfell  (Let's talk) 09:46, 20 April 2019 (UTC)

I also consider the "OpenStreetMap" prefix confusing. "Wiki" seems like a good option if removing the interwiki prefix doesn't prove to be too difficult, otherwise something like "OSM wiki" works, too.

But, taking a step back for a moment: Is there a strong reason for us to actively use that namespace? Not counting redirects, it contains less than 20 pages, and even pages about wiki maintenance (e.g. the Wiki guidelines or WikiProject Cleanup) often don't use it. It seems to me that we could just move the policy to "Wiki page deletion policy" in the main namespace (and "OpenStreetMap:Administrators" to "Wiki administrators" etc.) without significant downsides. --Tordanik 09:54, 20 April 2019 (UTC)

This name space is configured within MediaWiki by default. I mean we could investigate if we can remove it, but since it is created by default, I thought removing would rather break something within the software (the interface links to such pages for instance). I could not find any documentation about it. Some Stack overflow post suggested that this is not possible, but they were mainly talking about renaming and not removing. --Tigerfell  (Let's talk) 10:11, 20 April 2019 (UTC)

The low number of existing pages in the OpenStreetMap: namespace is mostly due to the namespace's confusing name. "Meta" pages currently live in the main namespace, which somewhat defeats the purpose of having namespaces. Moving meta pages into a dedicated namespace would improve search results, assuming that most people come to the wiki for tag and key description pages and WikiProject coordination pages, not pages about the wiki itself. – Minh Nguyễn ^💬 15:15, 22 April 2019 (UTC)

How about we move the following pages to the project namespace and update their names (naming convention, removing Wiki etc.)? OSM AuthPlugin, Wiki Help, Wiki Translation, Wiki Upgrade Problems September 2013, Wiki content license, Wiki guidelines, Wiki organisation, Wiki organisation/Proposal, Wiki syntax, Wiki userboxes, Help:WikiProject (including talk pages and translations)

That would leave Wiki and Searching the wiki in place. I do not really know where the pages Creating city pages, Creating country pages, Creating status pages, and Delete belong (basically how tos, but about the wiki). --Tigerfell  (Let's talk) 22:10, 22 April 2019 (UTC)

@Tigerfell: Are you proposing that we move those pages before or after renaming the OpenStreetMap: namespace? – Minh Nguyễn ^💬 00:08, 26 April 2019 (UTC)

I thought of doing this afterwards. I am waiting for the merge of the first pull request openstreetmap/chef/pull/232 ^GitHub which assigns the interwiki permission to the wiki administrators. Then I would ask a sysop to remove the 'wiki' prefix from the interwiki list. Next, I would open a second pull request for renaming the namespace and lastly I would move the pages. --Tigerfell  (Let's talk) 17:43, 26 April 2019 (UTC)

Just found Interwiki where someone already made requests for interwiki changes back in January. I would propose to move that as well. --Tigerfell  (Let's talk) 20:02, 26 April 2019 (UTC)

@Minh Nguyen: Great, now you can go ahead and remove Wiki from Special:Interwiki. I checked all of the links to this page, but none uses this prefix. Additionally, it would be helpful if you would update MediaWiki:Interwiki intro with something like

This is an overview of the interwiki table, which defines the prefix shortcuts used to quickly link to different wikis and other external sites. Administrators can modify them, please suggest an edit at ... For recommended use, please see the manual on MediaWiki.org.

I suggest to replace the three dots with either Project talk:Interwiki (I would then move parts of Interwiki there after renaming the project name space) or Talk:Wiki, whatever you prefer. --Tigerfell  (Let's talk) 20:27, 27 April 2019 (UTC)

Done and done. I also added WikiWikiWeb: as a more sensible replacement for the old Wiki: interwiki prefix, just in case someone really wants to link to that wiki for some reason. I linked to Project talk:Interwiki because this page is already really lengthy. Need to port over w:Template:Edit fully-protected and w:Template:Archive box at some point. – Minh Nguyễn ^💬 22:43, 27 April 2019 (UTC)

Thanks. I wrote some smaller version of Edit fully-protected at Template:Edit request. Please feel free to change, if useful I can add a doc as well. --Tigerfell  (Let's talk) 10:55, 28 April 2019 (UTC)

Skipped moving some pages, because I thought it would be of rather little benefit for fixing many links. --Tigerfell  (Let's talk) 21:06, 3 May 2019 (UTC)

Discussion about Interwiki prefixes

In case you are interested, there is a discussion about interwiki prefixes at Wiki talk:Interwiki. Interwikis are prefixes for linking to an external webpage i.e. not wiki.osm.org using the syntax of an internal link. There are essentially two ways of linking then:

• using external links: https://en.wikipedia.org/wiki/OpenStreetMap https://en.wikipedia.org/wiki/OpenStreetMap
• using interwiki: wikipedia:OpenStreetMap [[wikipedia:OpenStreetMap]]

These prefixes can be changed by administrators. --Tigerfell  (Let's talk) 09:14, 3 June 2019 (UTC)

Upload file clarification

https://wiki.openstreetmap.org/wiki/Special:Upload dialog claims "Media files that are not covered by the project scope of Wikimedia Commons, but are useful in OpenStreetMap wiki pages: for example media of State of the Map conferences, Humanitarian OSM Team projects, mapping parties."

But there are https://commons.wikimedia.org/wiki/Category:State_of_the_Map https://commons.wikimedia.org/wiki/Category:Humanitarian_OpenStreetMap_Team https://commons.wikimedia.org/wiki/Category:OpenStreetMap_mapping_parties and as far as I know this files are withing Wikimedia Commons interests. I propose to delete this line from interface or switch examples to correct ones. Mateusz Konieczny (talk) 05:31, 11 June 2019 (UTC)

Well, I guess the question is whether the content is "realistically useful for an educational purpose" from the Commons POV. Regarding your argument, I would cite

An otherwise non-educational file does not acquire educational purpose solely because it is in use on a gallery page or in a category on Commons, nor solely because it is in use on a user page (the "User:" namespace), but by custom the uploading of small numbers of images (e.g. of yourself) for use on a personal Commons user page is allowed. Files relating to projects or events of the Wikimedia community, such as user meetings, are also allowed.

As you might have guessed, I am not sure if the files are considered "educational". I would suggest asking at the Commons help desk. --Tigerfell  (Let's talk) 13:26, 11 June 2019 (UTC)

I asked in the past, scope of commons is interpreted extremely broadly and generally anything where use can be justified is not deleted under this rules Mateusz Konieczny (talk) 13:40, 11 June 2019 (UTC)

Language bar template rewrite

Template talk:Languages#Lua rewrite proposes replacing {{Languages}} (the language bar at the top of nearly every page) with a rewritten version that takes 2–3 seconds less time to load than the current version. On short key/tag description pages, that can be a reduction in load time of up to 85%. The new template also improves maintainability. Thanks in advance for your feedback. – Minh Nguyễn ^💬 16:25, 19 June 2019 (UTC)

<includeonly> in templates

The interesting bits of some wiki templates are surrounded by <includeonly>…</includeonly>. These templates (except documentation if there is any) are not visible on the template page or in preview. Is there a good reason for this or should it be discouraged? --Andrew (talk) 19:50, 1 July 2019 (UTC)

IMHO that is a question of personal preference. Three examples for illustration:

Template:Relation

The whole template is wrapped in <includeonly> and <noinclude>. If would you transclude the template without parameters, it will trigger an error and add the page to the category Pages with script errors. The categorisation is built in by Scribunto extension and I wanted to avoid false positives.

Template:Ambox

The template page contains the template, but without a mandatory argument, so you see an error message but also an Ambox itself. So you might be able to guess what the template is about without reading the doc.

Template:Az:HelpMenu

There is no <includeonly> and also no error and no categorisation. It actually does not use any parameters at all. The display is helpful for users who would like to see what the template is about without knowing the language or switching to a translation.

I hope that is somewhat illustrative. --Tigerfell  (Let's talk) 20:31, 1 July 2019 (UTC)

Language icons

I am redesigning the icons that indicate languages of linked pages such as {{French}} ((fr)). I would appreciate comments and suggested text for the tooltip in different languages. --Andrew (talk) 11:09, 5 July 2019 (UTC)

Conventions for categorisation

Are there any conventions regarding categorisation beyond Wiki guidelines#Categories? I would like to structure the categories a bit more and avoid cases like Category:Mapping Party in Taiwan versus Category:Mapping parties in Latvia. I am particularly interested in conventions regarding

• use of plural parties vs. party
• translation aspects
  • What is Category:Belgium/translations good for?
  • When to use the "English" category?
• geographical structures e.g. Category:Municipalities in Belgium, Category:Provinces in Belgium, Category:Regions in Belgium, Category:Cities in Belgium, Category:Hamlets in Belgium, Category:Towns in Belgium, Category:Villages in Belgium
• naming for A in B categories like Category:Belgian tagging guidelines but Category:Transport in Belgium
• use of abbreviations

--Tigerfell  (Let's talk) 22:04, 10 July 2019 (UTC)

A lot of pages wind up using categories as if they were tags like one would find in Flickr, probably because of unfamiliarity with MediaWiki and its conventions. I've been trying to clean up import page categorization, but the very strong convention of naming the categories "Import from ..." continues to bug me. I think it's fine to rename categories to be more systematic, within reason, as long as the categorized pages don't get lost. {{Category redirect}} can be helpful for that. – Minh Nguyễn ^💬 00:15, 11 July 2019 (UTC)

How would you name the import categories? --Tigerfell  (Let's talk) 12:11, 18 July 2019 (UTC)

"Imports in …". Technically the data is being imported from one country to another, but "Import from" sounds like a command rather than a category name. It's pretty nitpicky, so that's why I haven't bothered to make the change yet. – Minh Nguyễn ^💬 16:58, 18 July 2019 (UTC)

Some ideas of my own:

• constantly using plural, because most categories use the plural form already
• translation
  • Could not really figure out the reason for .../translation categories
  • I suggest to use it for English pages only, file categorisation depending on the content language. If there is no language or context I suggest using the English category.
• Maybe it is best to create categories only when there are pages in them.
• Naming categories <Topic> in <Country> seems more flexible and clear than the other variant
• I would advise against using abbreviations.

Some other things I came up with when looking at the current categorisation.

• Category names should be descriptive and not to broad like Category:Photos or Category:SVG.
• Category hierarchies should not contain loops.
• I suggest using the prefix Wiki (note the space) for categorising Wiki stuff like clean-up categories and templates.
• Categorising the format does not look like a good idea (like Category:Photos). I would suggest rather grouping events.
• A category name <Features> by <Country> seems to indicate a container category, but that does not mean that all container categories follow that schema.
• I suggest changing the language indication from prefix to suffix. Category:IT:Wiki would become Category:Wiki/it and avoid using slashes in any other case. This would avoid some codes being capitalised while other use lower case.

--Tigerfell  (Let's talk) 12:48, 19 July 2019 (UTC)

Update license choices for uploads

I suggest to update the list of licenses to choose from when uploading. You can find my suggestion at MediaWiki talk:Licenses. --Tigerfell  (Let's talk) 11:34, 21 July 2019 (UTC)

Resolving redirected categories

With regards to a user reverting the redirection of a category, because he thought the redirect "didn't work", I would like to suggest to resolve those redirected categories after a while. By resolving, I mean 'using a bot to change all pages in the category to the new category name'. There is a list of redirected pages which still contain pages. Any objections? --Tigerfell  (Let's talk) 19:58, 2 August 2019 (UTC)

I would of course check if it is reasonable to change the category and if it is not an error or a broken template that causes the categorisation. --Tigerfell  (Let's talk) 20:07, 2 August 2019 (UTC)

 Support --Dcapillae (talk) 23:32, 2 August 2019 (UTC)

 Support --Tordanik 15:40, 5 August 2019 (UTC)

Categories in Spanish

The categories in Spanish are not shown now in the language bar. Many categories in Spanish exist with the language prefix "ES" (Category:ES), but the template has now changed to use the prefix "Es" (Category:Es) by default. I don't know what I can do about it. There are a lot of categories in Spanish. Is it related to the redirects? What can I do to fix it? --Dcapillae (talk) 21:26, 9 August 2019 (UTC)

No, this is related to a recent rewrite of the language bar. The template now defaults to Es: for categories, but it recognizes either ES: or Es: if the category already exists. Note that, if the category name has been translated into Spanish, there needs to be a redirect or else the non-Spanish pages will be unable to detect the Spanish page. If the template isn't working as designed, please provide an example in Template talk:Languages and I'll sort it out. – Minh Nguyễn ^💬 00:09, 10 August 2019 (UTC)

Ah, in fact, the template did have a bug omitting links to any language with its own namespace in categories, templates, etc. This issue is now fixed. Thanks for spotting it! – Minh Nguyễn ^💬 01:49, 10 August 2019 (UTC)

Lua errors on Key- and Tag-pages

I'm seeing "Lua error in Module:DescriptionFromDataItem at line 822: attempt to index field 'wikibase' (a nil value)." on Key- and Tag-pages currently. Whoever broke it, please get it fixed again. --Lyx (talk) 19:17, 27 August 2019 (UTC)

See https://github.com/openstreetmap/operations/issues/325#issuecomment-525424195 Mmd (talk) 19:34, 27 August 2019 (UTC)

Wiki Adminship for Tigerfell

Some time ago, Yurik proposed me as an administrator in this wiki. I declined this, arguing that I would need some more experience, but I would be available at a later time. Today, I am in a situation where I would like to have unsused and broken Interwiki links removed, the list of licence choices being updated, and a shorter queue of deletion requests. Additionally, I would like to move the spam blacklist on GitHub to this wiki, so that administrators can edit them without requesting changes from the system administrators. Each of these actions require administrator status. That is why I would like to propose myself for becoming an administrator.

I am an active wiki contributor, who translates articles, updates the calendar, participates in discussions about the wiki, assists others, and does general maintenance. I often review Special:RecentChanges, but try to let others edit the wiki in their own ways without forcing my ideals on others. I have asked the system administrators to add multiple extensions to the wiki (like “Thanks” extension) and to update some settings (tile inclusion via HTTPS, automatic redirect resolution, renaming the project namespace) following user requests (List of my changes to the configuration). Since November 2018, I am working on a solution to replace Slippy Map extension.

On the negative side, I want to name the fact that I was possibly too optimistic or too inexperienced when starting DE:Proposed features/Empfehlung zur Verwendung von Multipolygonen(de), a proposal about when to use multipolygons instead of closed ways in Germany, and Wiki:Deletion policy, for which there was no consensus in the end. I would say that I have learnt that sometimes there is no consensus or at least you are not the right person to establish one and then it is better to withdraw and that writing a proposal is more difficult when multiple people do it together.

Perspectively, I would like this wiki to gain and maintain a supportive role for the OpenStreetMap project.

Since there is no established voting process for wiki administrators, I suggest that you indicate whether you approve or disapprove my nomination below. A bureaucrat could make a decision when everyone interested have placed their vote. Please also feel free to pose questions. --Tigerfell  (Let's talk) 18:36, 4 September 2019 (UTC)

 Support --Dcapillae (talk) 18:44, 4 September 2019 (UTC)

 Support good helpful contributor. --Yurik (talk) 00:10, 5 September 2019 (UTC)

 Support -- Naveenpf (talk) 01:23, 5 September 2019 (UTC)

 Support Tigerfell has shown deep commitment to this wiki's health and enthusiasm for its continued development. – Minh Nguyễn ^💬 05:25, 5 September 2019 (UTC)

 Support --Władysław Komorek (talk) 18:23, 5 September 2019 (UTC)

abstain -- I value your contributions but am not convinced you have enough experience and the deletion discussion is still in fresh memory. On the other hand bad experiences are sometimes the most instructive ones so I am not against. RicoZ (talk) 22:17, 8 October 2019 (UTC)

 Support -- Harry Wood (talk) 15:10, 28 October 2019 (UTC) . It's clear Tigerfell is enthusiastic, and I think we could probably do with a bit of that on our little list of wiki administrators. Although it's important for admins to weild their power in a slow and thoughtful way, sometimes we're a bit slow and unresponsive :-)

 Support --Tordanik 20:32, 28 October 2019 (UTC)

There was no activity here for about a week, but I was asked to act on Talk:Portugal, so maybe the bureaucrats (@Firefishy:, @Harry Wood:, @Lyx:, @Pigsonthewing:, and @Steve:) could make a decision? --Tigerfell  (Let's talk) 06:16, 13 September 2019 (UTC)

I am unclear as to what the process is for agreeing a new admin; and it does not seem to be documented. Can anyone point to a prior case or cases for precedent? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:51, 10 October 2019 (UTC)

You can find my take on the issue three sections down on this page. --Lyx (talk) 22:45, 10 October 2019 (UTC)

Yeah there's no process. We're only little wiki, so we don't have a full chain of processes and rules in place. The common sense buck stops with the administrators! Any objections to adding Tigerfell? -- Harry Wood (talk) 15:10, 28 October 2019 (UTC)

DONE Y - User:Tigerfell is now an administrator! (See Special:Listadmins). -- Harry Wood (talk) 21:47, 30 October 2019 (UTC)

Merge zh-hans and zh-hant to Zh, and Reform the translation process of this wiki

As mentioned here, it is really hard to maintain both Traditional and Simplified Chinese. It is also unnecessary since the only difference between the two are vocabulary. It is also a really simple task (It is a built in feature for MediaWiki) and I do not understand why it take so long for this wiki to do this. All the admin need to do is to use Special:PageLanguage to change the language of the Chinese page to Zh, this will automatically enable the Language Conversion listed here on Mediawiki. Change page language to zh-hans or zh-hant will not trigger the conversion tab, you have to change it to zh, see here for an example. In this test page I create, the conversion tool is displayed with page language set to zh.

Since the language conversion problem is solved, it will be the best to deprecate of both zh-hans and zh-hant, and re-list zh so translators like me could easily maintain pages with one language code rather than six language codes.

However, letting admin to change every page's language is ridiculous, and the current translation process of this wiki is ridiculous as well. The Translate extension can automatically use Page Content Language Hook of MediaWiki to automatically add the correct page language once the page is created. It is also an ease for translators to translate the pages (I translate on the translatewiki as well as meta-wiki, and the translation extension is absolutely a lifesaver). I understand there is a discussion a few months ago. However, I would really want to bring back discussion since the extension's benefit outweighs the disadvantages.

The Translate Extension can provide translators a general idea of how many things that waiting to translate, update and proofread. You can see Statistic of Metawiki to have a look. The extension can eliminate the need of maintaining {{Translated}} by only use <language />(Which will be automatically put by the extension). The extension also eliminate the need of manually put {{Translation out of sync}}} on pages, since it automatically flag the changes made is the source (like the exact wording it changed) and present the outdated translation to the translators. The translated page itself will also flag the outdated translation with colored background. The most importantly part is that the extension eliminate the need for translator to figure out the layout issue after translation and only focus on the translation. For example, I just started translate Wiki to Zh-hans:Wiki and I still cannot figure out what went wrong with the layout. If Translate extension is implemented in this wiki, I will not need to worry about this since the extension will take care of this automatically.

I see some people argue that "especially the requirement to clutter the English text with various markers that make wiki editing less accessible to non-technical editors" and it is a mess. I just want to say that please look at the MediaWiki Translation guide, you do not need to add these tag manually, the extension will automatically add these tag for you. Also, adding the tag should not interfere with the ability of editing since visual editor will not read the tag and people who use wikiEditor should have enough knowledge for basic syntax.

It will also great to eliminate language namespace and use /zh, /jp format (which is the same format as wikipedia). I understand the original purpose for having language namespace is [Wiki_Translation#Language_prefixes_and_namespaces|easier for search]. However, with [1] installed, you can define narrow the search based on page language and prefix, which solve this problem.

Overall, I hope this community could consider my suggestion and implement the following step:

1: Merge zh-hans and zh-hant to Zh (This should be easy and quick).

2: Install the Extension:Translation

3: Convert the current naming of translation for Zh-hans:wiki format to wiki/zh (This step may be necessary since it seems extension:Translate produce page in this format.)

VulpesVulpes825 (talk) 14:52, 6 September 2019 (UTC)

You can use Special:PageLanguage by yourself as every user is able to change it. I would say, that we are currently on our way to remove the namespaces slowly no matter if we introduce the extension or not. --Tigerfell  (Let's talk) 17:08, 6 September 2019 (UTC)

All right, I will start to change the language and merge zh-hans and zh-hant to zh, as well as change Module:Languages/config to reflect this. However, I would still like to continue the conversation about having Extension:Translate. VulpesVulpes825 (talk) 18:10, 6 September 2019 (UTC)

Rename a wiki page with wrong title

Hello. I don't know if this is the right place for this request. So feel free to delete this if it's wrong here.

I created the wiki page DE:Key:lcn=yes. According to the naming conventions the Page should be called DE:Tag:lcn=yes instead. I can't correct the name of the page by myself. I would appropriate if an admin could fix my mistake.

Page has been moved. --Lyx (talk) 19:26, 24 September 2019 (UTC)

Creating new Wiki Admins

As you might have noticed there is no published procedure how to create new Admins in this wiki. The procedure I have used so far is "forward requests to firefishy", possibly with an added comment what I think of the request. I expect to continue following that procedure in the future. However, I'ld like to tell you what the role of Wiki Admin and the requirements to fill it should be in my opinion. Please note that this is only my personal opinion and in no way an official position, and the fact that I am one of the Admins doesn't make my opinion any more or less valuable than the opinion of any other community member.

The role of a Wiki Admin is IMHO a serving and moderating role. Therefore an Admin should try to keep a neutral position in discussions in this Wiki, preferably keeping completely out of heated exchanges except for trying to moderate the tone, maybe summarize the positions of all sides and help the community find consensus. There are cases where quick action is required; in those cases make sure that those actions can still be discussed. --Lyx (talk) 19:57, 24 September 2019 (UTC)

@Lyx: there are two separate tasks that require adminship -- moderation and UI administration. I agree about your thoughts about moderation aspects, but there is also a number of changes that require the person to be trusted with technology - i.e. being able to change javascript for all users of the site. Moreover, usually there are far fewer UI admins than moderation admins (as we can see with the English Wikipedia, where such division was introduced a year or two ago). We do not separate those two roles, simply because size-wise OSM wiki is far smaller than EN Wikipedia, so this division is excessive, but we should always keep in mind that UI adminship is a valid and frequently required skill. --Yurik (talk) 23:43, 10 October 2019 (UTC)

LaTeX <math>..</math> Extension

Wer kann im OSM-Wiki die Erweiterung zur Darstellung von Formeln installieren? Gruss, --Markus (talk) 20:25, 10 October 2019 (UTC)

Please can you install https://www.mediawiki.org/wiki/Extension:Math to the OSM-Wiki? Thanks for help, --Markus (talk) 22:31, 11 October 2019 (UTC)

The system administrators can do that. You can create a ticket for them at https://github.com/openstreetmap/operations/issues (same address as provided at the very top of this page). In theory, a wiki administrator's approval is desired. --Tigerfell  (Let's talk) 12:51, 13 October 2019 (UTC)

Help profiling a template

I have a revised version of {{LangSwitch}} based on the Wikimedia Commons version. How can I time the effect on page performance? --Andrew (talk) 21:15, 13 October 2019 (UTC)

You can transclude the template on a sandbox page and after creating the first preview, there are some data about CPU and real time usage in the section "Parser profiling data" below the editing box just above the categories. There are also browser tools as part of many web browsers. There are run time analysis and network analysis for instance. The usage of the web console for MediaWiki was briefly explained in Talk:Wiki/Archive 5#Optimizing wiki templates. --Tigerfell  (Let's talk) 21:17, 14 October 2019 (UTC)

Possible spam account

Please take a look on https://wiki.openstreetmap.org/wiki/Special:Contributions/Lavie_Labs_Hydrolift_Review . I've already wiped his SEO spam.--Kundera (talk) 13:26, 14 October 2019 (UTC)

@Tigerfell: More spam users -> User:Visirestore Review.--Zhukov (talk) 09:17, 12 November 2019 (UTC)

@Minh Nguyen: Administrators, please do something: User:Subliminal Guru Review 2‎; User:Gluco Type 2 Review Tab‎; User:Floraspring Review‎.--Zhukov (talk) 11:58, 12 November 2019 (UTC)

All of the accounts were blocked (not by me). I temporarily blocked the creation of accounts with names similar blocked to these ones. Hope that helps. Blanking or replacing the content with {{d|spam}} is usually sufficient as a first measure. --Tigerfell  (Let's talk) 20:06, 12 November 2019 (UTC)

Template: Mini-map around a node/feature

I'm looking for a template that embeds on a wiki page a small map of the area around a given node. The Templates index has one that does very roughly what I'm looking for: Template:Node transcludes a link to the map at the node specified.

The result can be simplified using Template:NodeIconLink, but I can't see how to give more info: I want an image (slippy or not) of that node in its context. (I don't want to have to click the link and open the map on another page to see this.)

I've also looked at Wiki:Maps (thanks again @Tigerfell:). I think to embed a map I need to manually find a node's lat-long to specify which bit of the map is shown, and I just want to code the node id. (As it happens the next question will be: is there a template that will display the lat/long for a given node?)

Any pointers? Fwiw this relates to the wiki page Sustrans Millennium Mileposts. Many thanks, eteb3 (talk) 20:46, 27 October 2019 (UTC)