Talk:Wiki

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

If you have ideas for technical improvements to the way the wiki works, e.g. extensions we should install, you might add them here, and/or create issues in GitHub: openstreetmap/operations/issues/ ^GitHub. Older requests can be found in trac (raised as 'component=wiki'): https://trac.openstreetmap.org/query?status=new&status=assigned&status=reopened&component=wiki&order=priority

Older requests can be found here:

---

Bug: map appears below map div at normal desktop window sizes

No map appears "above the fold" in the space for the map (<div id="map" class="olMap">) unless I resize my browser really wide. Instead the map displays partway through the first paragraph, obscuring several paragraphs and headings.

This page specifies <slippymap h=480 w=720 z=11 lat=37.35 lon=-121.98 layer=cycle></slippymap> and in most portrait windows there isn't room for a 720-pixel wide map alongside the place table. You could move the {{Place}} template invocation below this to avoid the problem, or insert a <div style="clear:both;"></div> between them, or rethink the CSS of Slippymap and the {{Place}} template.

Bug: JavaScript error

If I turn on my browser's JavaScript console, I see

 TypeError: OpenLayers.Control.Button is not a constructor
  slippymap_init()      South_Bay_(SF),_California:87:1096 [in the page HTML]
  <anonymous>

Mr. Hughes comments this is probably a bug in the SlippyMap extension.

The slippymap extension is full of bugs, including with very bad HTML/CSS layout. In addition it can only be used only ONCE per page. Trying to display two maps on the page will incorrectly place the children elements or will cause the interaction with one map to affect another map due to collision (no unicity of the generated "id" attributes per slippymap instance).

This local gadget on this wiki is in fact unmaintained since long and nobody seems to be working on it (and it is not part of the standard MediaWiki distribuion, not used by Wikimedia on its sites that uses other extensions and is developing new ones for integrating maps in Wikipedia: for now there's a couple of extensions used to render maps in a popup that you open by clicking on a "map" icon at top of page at end of the title bar.).

Probably it will be replaced later using a new installed gadget or extension. But for now, if you need several maps, use separate wiki pages.

Additionally the slippymap also uses deprecated features of MediaWiki and unsupported internal features that no longer exist. And yes the use of the OpenLayers framework is also non-conforming (as it also uses internal variables in a non-clean way not matching the documentation). slippymaps on this wiki have very limited usage, just to show a basic locator map for the country, region or city which is the main topic of the page. In most cases one one map may be useful; for the rest, create directly a link to the OSM site to render maps in a separate page: you can use templates like {{Node}}, {{Way}}, {{Relation}} to create such links to the OSM map or to a few other tools with specific renderings. — Verdy_p ^(talk) 15:57, 12 June 2016 (UTC)

ResourceLoader warnings

I also see in the console the warnings

 Use of "addOnloadHook" is deprecated. Use jQuery instead.
 Use of "wgNamespaceNumber" is deprecated. Use mw.config instead.
 Use of "addOnloadHook" is deprecated. Use jQuery instead.

Probably some extension is calling these. The ResourceLoader Migration guide has advice on updating to avoid these deprecation warnings. In some future MediaWiki release they will all become errors.

This has been signaled already, and simple to solve:

• addOnloadHook(function) must be replaced by $(document).load(function) (this will effectively use the resource loader in a predictable load order to avoid collisions of scripts, or bad effects produces by browser and proxy caches where the order of loading defpendant scripts is unpredictable: a dependant script may not be loaded when another script needing it will start referencing a feature)
• wgNamespaceNumber must be replaced by mw.config.get('wgNamespaceNumber') (this nas no relation to the resource loader but to a more modern use of the global variables (keeping only "mw" as a global for the builtin MediaWiki environment, it becomes much simpler to isolate only this one to sandbox some behavior, without having to rebuild long lists of variables in the environment; notably using the get() method allows simpler overrides, that will be consistant across extensions or for custom plugins, without causing plugins to have side effects, as all that will be needed is to override the get() method to define a specific behavior; this is needed for the various editoes or for helping the development of betters skins, or better tune the interface for mobiles, or to simplify the work in customized user-specific behavior and preserving a wider compatibility with other skins or between the modile and desktop version of the wiki, by using more selecting remappings, easier to define).

— Verdy_p ^(talk) 10:13, 3 June 2016 (UTC)

Restored this discussion (bug in slippy maps still not fixed after years)

Discussion restored from the archive, because the bug is still there in the old SlippyMap extension created for this wiki, which does not comply to basic requirements and isolation. We still need to fix this extension. For example it's still impossible to render multiple slippymaps on the same page. The only alternative is to use static maps.

The CSS and Javascript code for the SlippyMap extension has not been fixed since years and contains numerous issues reported since long. But not maintained. It has even blocked at some time the migration to newer version of MediaWiki due to compatibility issue. The slippymap extension used in Wikipedia (different versions depending on languages) is much better, faster, and maintained. MEdiawiki will also soon standardize a new version that will work across wikis with less security issues and more accessibility. However it depends on Wikibase and this wiki still does not have this extension and cannot work with remote databases (such as Wikidata).

So it would be good to revive the specific opensource code for the few extensions specific extensions used on this wiki, and finally fix all the severe issues reported. But this requires personal involvments of admins of this wiki, which are in fact not maintaining this wiki at all, and just too busy working on the OSM database instead. There's unfortunately NO active admins on this wiki to fix what they are the only allowed people to fix. And other people just have to find some workarounds, even if they are sometimes very slow or require lot of manual edits for the maintenance. — Verdy_p ^(talk) 15:35, 24 May 2018 (UTC)

Static map extension using HTTP, instead of HTTPS like this wiki

Final note: the static map extension still uses MIXED HTTP content in this HTTPS wiki. This also causes issues and some people not seeing the static map rendered at all in their browsers using strict security rules (especially as the map tiles come from another domain than this wiki). The URLs used for linking to the static map requested should also use HTTPS. — Verdy_p ^(talk) 15:41, 24 May 2018 (UTC)

Links: Case Sensitive and Namespace

Hi,

caused by the new on demand search function some pages hide themself for the user just cause he didn't captitalized the first character. Similar problems on namespaces. Are there any mediawiki extensions that solve this problem by allowing links and searches independent from Namespace or capitalisation? --!i! 12:55, 3 November 2010 (UTC)

MediaWiki:Lang/xx pages

There was some discussion whether the sitenotice (currently license change info) could be translated depending on the user's interface language. However, it seems that neither features such as {{int:lang}} nor branching to MediaWiki:Sitenotice/de work in the OSM wiki. Documentation on Wikimedia Meta seems to indicate that language switches using {{int:lang}} require the existence of MediaWiki:Lang/xx pages such as these. I'm not sure whether that actually works the way I imagine, but it would be useful if it did, imo. --Tordanik 04:14, 22 January 2012 (UTC)

Yes, this is true. I also ask for a wiki administrator to import these small messages. And then we will ease the translation of this wiki, notably in templates, like what is being performed in Wikimedia Commons. This is really a useful thing, and I have asked for this support in several places. — Verdy_p ^(talk) 03:25, 19 February 2012 (UTC)

per-page usage stats

Hi there. There is an entry about this form 2008 in the Archive, but nobody answered back then. Is it possible to get per page usage statistics for the wiki? Wikipedia has this on some external server: http://stats.grok.se/en/top I have no idea about the technical background. This would be immensely useful for directing translation effort as we could tackle popular pages first. --Chaos99 08:10, 15 February 2012 (UTC)

too-many-function-calls warning on a lot of pages

Thousands of sites are listed in the Category:Pages_with_too_many_expensive_parser_function_calls (to which I can generate no wiki link??) for to many expensive parser function calls. I tracked that down to the Template:Language, where too many #ifexists are used. I don't have a solution for this, but if there is none, we can omit all the warnings while editing and the automated categorization, as they don't add any information (and it might save some parser calls by itself).----User:Chaos99 08:00, 15 February 2012 (UTC)

See above, user:Verdy p worked on the corresponding templates but he currently hadn't fixed that bug. I will ask him again :) --!i! 11:04, 15 February 2012 (UTC)

I don't thinks that's a bug that can be fixed in the language template. To keep it's functionality, it has to do those #ifexists calls. It's just that we can ditch all the warnings at the edit pages if this really IS unresolvable. --Chaos99 12:16, 15 February 2012 (UTC)

Well sadly this bug occurred since Verdy did the edits. As far as I can understand (I'm not a template expert), the functiaonality is now to modularized. But verdy gives a real detailed explaination at User talk:Verdy p#Too_many_parser_calls and he would like to fix it with the assistance of a Wiki Admin --!i! 14:37, 15 February 2012 (UTC)

I've proposed a solution that works more or less for now, but something else must be implemented for the longer term. See my page for the reply and the complete description of the problem and how I solved it (temporarily). There's more work to do, but there's never been any more problem than what there was before, with lany links not appearing properly (I am already performing lots of cleanup within inconsistant links and redirects caused by various renamed pages and a severe lack of maintenance of this wiki for too long).

Yes there remains quirks, but much less than before.

In my opinion, the use of #ifexist should be completely deprecated, and we could avoid having to create many pages for each translation and maintain them, if we could support "autotranslatable templates" like in Wikimedia Commons. This just requires importing a few message resources in the "Mediawiki:" namespace, notably Mediawiki:lang containing "en" (the default language of this wiki) and its subpages (one for each language code, containing exactly the same language codes already listed in the users' Preferences page and supported by MediaWiki's interface translation). With those few small resources the documented wikicode "{{int:lang}}" would work properly instead of returning for now the static string "<lang>" that appears for resources that do not exist in a basepage of the "Mediawiki:" namespace. — Verdy_p ^(talk) 03:21, 19 February 2012 (UTC)

ParserFunctions version

I have been trying to write a template that formats dates in different languages using the third parameter to the Mediawiki #time function but #time is always returning English names for months. I notice that the language option has only recently been added to the documentation so maybe our ParserFunctions is too old for it to work. --Andrew 09:58, 3 March 2012 (UTC)

Mediawiki extension for inclusion of sections

Hi, could somebody of the Wiki-Team evaluate if this extension can be installed (or maybe is already installed)? It would enable to include sections of a wiki page into another, like a definition table from one language version to another.

http://www.mediawiki.org/wiki/Extension:Labeled_Section_Transclusion

This might hit performance do to parser calls, so please take that into consideration.

Thanks --Chaos99 08:30, 19 March 2012 (UTC)

Translations

Hello, I think that translation on this wiki would use some improvement and I've proposed a new system at Talk:Wiki Translation#Translate extension. Thanks, Nemo 10:24, 16 August 2012 (BST)

The referenced discussion ended with the announcement that the extension would be installed during the next MediaWiki upgrade. It seems that a software upgrade has happened yesterday, but the extension is not currently installed. Is this topic still on the admins' roadmap? --Tordanik (talk) 19:28, 31 January 2013 (UTC)

Invert translated local pages

In France, all the regional or departmental pages have the prefix France: and the name of the region, but in french - I think, it's logical. My deparment have a (older) english page as main page, and a "translation" in french - I means, this don't is systematicly. I will restructure the page in french, with subpages etc., and actualize the content. Can someone change the addresses, so that the main page is now french (and the history is'nt deleted) ?

Actualy, the two pages are here : - [1] - [2]

I think, the english page can be moved on the address http://wiki.openstreetmap.org/wiki/EN:France:Pyr%C3%A9n%C3%A9es-Orientales, then move the french page on the main page, http://wiki.openstreetmap.org/wiki/France:Pyr%C3%A9n%C3%A9es-Orientales, and then I can add a redirect for olds bookmarks and links, and create my subpages. --CepVingraunais (talk) 15:32, 18 February 2013 (UTC)

I think this should not be done. It probably breaks templates - and possibly parsers - that rely on the convention that non-English pages will use the language prefix if the page exists in more than one language (as I've already said here). --Tordanik 15:50, 18 February 2013 (UTC)

actualy, is not a prefix there (:fr is a suffix). (And the France: prefix already indicate that this is a "french" page...). Then, I have a problem with the subpages. Probably is the hierarchy false, when I put a french page like .../France:Pyrénees_Orientales/subpage -- But all subpages in a very complicated address, where the english page stay the unique english page of this theme ?... The convention, that all region pages of France have the form .../France:region_name is broken too. (sorry, my english is very very bad...) --CepVingraunais (talk) 09:29, 19 February 2013 (UTC)

Searching templates

This is an improvement for the search box in the upper right of the page. I extensively use this functionality to check for tags existence. Current search settings do not look into templates. IMO this is problematic as mappers can miss pages when searching tags. I know I can go to Special:Search, click Advanced and check Template checkbox, but it's a pain (and average mapper won't do it). Example of non-matching searches (you need to check the Template checkbox in advanced search to have a pertinent result):

• barbed wire fence, no (pertinent) result but present in Template:Fence_type.
• cereal bank, no (pertinent) result but present in Template:Map_Features:man_made.
• taekwondo, no result but present in Template:Map Features:sport...

Would it be possible to also search in templates by default? --Oligo (talk) 21:13, 11 July 2013 (UTC)

wiki dump

Is wiki dump service still available? This link http://dump.wiki.openstreetmap.org/ is already dead. Kcwu (talk) 08:38, 17 January 2014 (UTC)

It *still* isn't available. Who can get this fixed? --Tordanik 23:21, 2 April 2014 (UTC)

• reported at https://github.com/openstreetmap/operations/issues/179 Mateusz Konieczny (talk) 16:17, 8 November 2017 (UTC)

Navigation by use cases

I proposed a reorganisation of the wiki navigation, which is also somehow a larger restructuring project. I would be happy to get your opinions about it. --Cantho (talk) 05:22, 28 January 2014 (UTC)

wiki search

The search results that drop down from the search box while you type don't include redirecting pages anymore. Who can change that? --LordOfMaps (talk) 08:22, 22 April 2014 (UTC)

ORCID identifier template

I created {{User ORCID}}.

ORCIDs (Open Researcher and Contributor IDentifiers) disambiguate people - like an ISBN or DOI, but for humans.

Any OSM editor may register, free, for an ORCID identifier, at the ORCID website.

If you have an ORCID identifier, please use the template on your user page. And please feel free to improve the template! Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:10, 8 June 2014 (UTC)

Request for namespace with machine-readable definitions (XSD:)

Since required tags and regexes for values were requested, we can skip this step and use xsd definitions directly at wiki. Obviously this namespace is not translatable.

Right now we use wiki as knowledge base for OSM (proposals, external references to wikidata), so code snippets will not harm IMO. Probably we can use more generic name "formal:":

• formal:Tag:amenity=public_bookcase
• formal:Key:operator
• formal:Key:operator:type

Formal definitions will be limited per their scope:

1. formal:Key: will cover single key
2. formal:Tag: will cover single value
3. formal:Proposed features/Animal_breeding may cover entire tagging schema as described in Proposed features/Animal_breeding

1 and 2 are hard to formalize correctly if there multiple overlapping schemes (see type=*). Formalization of 3 looks more promising.

This namespace should be excluded from search results (see [3][4] and relevant settings).

Actually this idea not so crazy, many authors of validators invent their own checks instead of reusing common knowledge. Xxzme (talk) 04:14, 23 February 2015 (UTC)

If we go the machine readable route, then I would prefer having a Wikibase instance for the OSM wiki, ideally with one Wikibase item matched to each key (and software etc.). That way, we could e.g. also store information for the infoboxes in a central location, and re-use them across language versions and even for lists such as taginfo. --Tordanik 11:28, 23 February 2015 (UTC)

Semantic MediaWiki

Hi all,

I want to bring up an old topic again, namely how you feel about adding the Semantic MediaWiki extension to this wiki. It seems that this has already been a topic in 2009, wich found neither strong opposition nor wide support in the OSM wiki community. Since the focus in 2009 was rather about machine-readability than maintenance facilitation on the one hand, and on the other, we are now 2016, and both OSM wiki and SMW have come a long way since 2009,

I want to ask anew what you think about installing SMW on this Wiki?

Some points I see speaking in favor of SMW are:

• It can be used to automatically update lists (e.g. map features like Template:Map_Features:shop, user lists, etc.)
  • (As usual, those lists could use templates for styling & layout through the template format output, this was not possible in 2009 as it seems)
• It can make maintenance tasks much easier because it allows to query for combinations of categorisations and other page properties (even complex queries for tracking things like localised pages which do not have the same property x as page <pagename> could be made possible without further workarounds!)
  • Tailormade maintenance ToDo lists
• Other possibilities include:
  • A {languages} template setting & using a common page property for translations of an article -> no need for redirects anymore, works across all namespaces
  • A single, common database for tag descriptions to which new tags can easily be added from every language
  • Many useful things which I don't know about...

Please tell me what you think!

Cheers, Charel (talk) 13:51, 29 April 2016 (UTC)

I think some semantic support for the wiki content would be very useful, for automatic list generation, easier access to tag data via queries/api and so on. Since you seem knowledgeable about the topic, how do you feel about the relative merits of SMW and a Wikibase installation for this purpose? --Tordanik 13:42, 5 May 2016 (UTC)

Proposal for creating group categories

Hello, I would like to propose to start creating group categories for tags and keys as it was intended while adopting a new {{Description}} template. Actually it the process of creating group categories is working since rolling out this template but the destination categories were mostly not created so the groups were missing or were almost empty and when the category for the given group does not exist it won't be created automatically and tag/key is not included in it and stays in parent category.

These are the groups I am talking about:

• Category:Key descriptions by group
• Category:Tag descriptions by group

There is one problem however which needs to be sorted out before I or anyone else can start creating the missing categories for tags/keys. The problem is with the group= parameter of {{Description}}. As you might know the parameter in the current version of the template is displayed with the initial letter capitalized. Therefore it does not matter if you add group=Highways or group=highways it gets displayed as Highways. The problem is that the same logic was not applied when sorting the tag/key into appropriate group. The is no capitalization applied and therefore group=Highwasy and group=highways tend to end up in two different categories which is undesirable.

Unfortunatelly there was no standard for case of this group= parameter clearly defined. Therefore we have a mixture in the wiki of both styles. I have done some counting and the statistics is:

• 12 244 tag/key pages in total in all languages
• 5 055 has a group= group filled in
• 4 109 are starting with capital letter - group=Highways
• 895 are lower case - group=highways

Now there is a lengthy and heated discussion between User:Verdy p and User:chrabros how to solve this and proceed with categories creation. The discussion starts here and continues here and you are welcome to join it. My conclusion of this debate is that we have several options how to proceed and those are:

Option 1 - Capitalize first letter of Group

• + it is a simple change of {{Description}} template
• - we need to recreate 10 categories in Category:Tag descriptions by group and 71 categories in Category:Key descriptions by group
• + we do not have to edit any tag/key pages
• + the value of group displayed in right hand side infobox will be the same as category name which are users used to for a long time now
• + group=Highways and group=highways will end up in the same category automatically
• - we cannot have any category name starting with first letter lowercase (I cannot think of an example where it matters)

Option 2 - Make the first letter of group lowercase

• + it is a simple change of {{Description}} template
• - we need to recreate the existing group categories
• + we do not have to edit any tag/key pages
• - the value of group displayed in right hand side infobox will be different to the name of a category name, but it is just a cosmetic problem
• + group=Highways and group=highways will end up in the same category automatically
• - some users (for example Germans) will not be happy as they like their capitals in words

Option 3 - standardize group parameter as lower case for English, any case for other languages

• + no change of {{Description}} template
• + no need to recreate the existing group categories
• - we need to edit 1 040 English tag/key pages from group=Highways to group=highways and up to 4 109 tag/key pages in other languages depending on their choice.
• - the value of group displayed in right hand side infobox will be different to the name of a category name, but it is just a cosmetic problem
• - group=Highways and group=highways will try end up in different categories. This means that we will have to watch out all the time in the future that new edit/additions are adhering to the standard.
• + users of other languages (for example Germans and Czechs) can name their categories as they like with upper or lower case

Option 4 - standardize group parameter with first letter upper case for English, any case for other languages

• + no change of {{Description}} template
• - we need to recreate the existing 81 group categories
• - we need to edit 84 English tag/key pages from group=highways to group=Highways and up to 938 tag/key pages in other languages depending on their choice.
• + the value of group displayed in right hand side infobox will be the same as category name which are users used to for a long time now
• - group=Highways and group=highways will try end up in different categories. This means that we will have to watch out all the time in the future that new edit/additions are adhering to the standard.
• + users of other languages (for example Germans and Czechs) can name their categories as they like with upper or lower case

Option 5 - automatic, but different standards based on language

We could change the {{Description}} template to automatic capitalization based on language so we can use group=highways in English and group=Highways for some other languages if they want to do so.

• - {{Description}} template needs to be adjusted by someone experienced accordingly, but it is not a huge change
• + no need to recreate the existing group categories in English
• + we do not have to edit any tag/key pages
• - the value of group displayed in right hand side infobox will be different to the name of a category name for some languages, but it is just a cosmetic problem
• + group=Highways and group=highways will end up in the same category automatically
• + users in different languages will be able to decide on capitalization as they want

Those are the five options I can think of. I would like to ask you to think about them and state your opinion here. I believe that the group categories are quite useful and it is a pity we don't use them so far. I personally would like to go on with Option 1 or Option 5. Thank you very much for your opinion. Chrabros (talk) 04:26, 16 March 2017 (UTC)

Talks

You also note that whever you use group=highway (initial version used since the begining) or group=Highway (used to fill various tag/key pages later, without knowing the effect) this displayed the same thing in the infobox as "Highway" was capitalized. This forced capitalisation is not desirable for all languages (e.g. English frequently uses a capital after a colon in "Group: Highways", but French wants to keep lowercase after the colon, and capitalize only proper names). for infoboxes, this forced capitalization shjould be removed (but kept only for English or the few languages that want it). It has no effect on Japanese where non-proper names will be translated there.

Initially group names were intended to be lowercase including in English, just because it would frequently (but not always) match some OSM tag key names. Note that tag key names are generally using a singular name, while groups are intended to be larger and will typically use plural forms, and don't have to be limited to the same OSM tag key. Groups are intended to be translatable (unlike OSM tags which are unified in British English as much as possible and use sometime a specific OSM "technical jargon" or abbreviations, including the fact that it uses underscores instead of spaces that would be used in group names)

So we must think about group names to use regular linguistic rules.

The discussion here is only about how to write the category names: Category:(Tag|Key) descriptions for group "groupname" which in normal English would also be written normally using lowercase (which I don't think should ever need to be changed to use capitalized group names here). This discussion has no effect when there's a matching "Category:Groupname where it is capitalized by default like every page in any namespace (even if this group name is translated and occurs after a language code prefix). Since the begining these categoies were using lowercase and this was never contested by anyone, even when they started being translated. Some of them were initially correctly filled. Errors started later because there was initially a correct example in the documentation page (for group=shop), followed then by a new added example (group=Historic) using another case convention (at that time the categories for this second example did not even exist: this example was not properly tested and duplicate categories were created later for this example group!). At that time, groups were still experimental (and I think they are still experimental, no one has seriously thought about how to organize these groups, this is only initial setup waiting for more organization)

The statistics above are not very relevant: initially they were completely reversed. Confusion about lettercase started to occur because some people have not cared at all about group names but just wanted to categorize their tags in other categories (Category:Groupname) and make this visible directly in the infobox. Note also that the chosen name Category:(Tag|Key) descriptions for group "groupname" is probably overlong but this was not really discussed. But as they are transaltable, some languages use another scheme (e.g. Japanese): all is translatable, including the surrounding quotation marks.

Note: the statistics have also been largely skewed by Chrabros silently adding group parameters in many key/tag pages using capitalized initials in Czech and English pages and some others (even replacing those that were correctly setup initially with lowercase)! So Chrabros has emptied silently some categories and argues now that they are empty and unused (this was wrong, this was an error by Chrabros himself) !

The name was first specified in Template:DescriptionCategoryLang (which has only been tuned and used for a few languages: cs de es fr ja, other languages using the same English default): none of these are using groupnames, this was the initial setup. This template is still used but not with the "group" parameter, but instead with the "status" parameter (also using lowercase in its English value...).

Then Template:DescriptionCategoriesLang came to replace it, in order to add support for the new experimental "groups" (and conditional use of groups): groups were activated only in English, French, Japanese, German, Spanish, Greek (still not used), and Czech (in that order, Czech being the last one added a fews days ago by Chrabros making the proposal above), all other languages having groups disabled by default (knowing the fact it was still experimental and requried active contributors to follow the tracks). That template came after a long discussion above to unify the various translation schemes to allow for simpler start for languages that have few pages translated (without having to force them to create many subcategories, just a few basic parent categories: navigation in subcategories in this case requires visiting the matching English category to find relevant subcategories). That template documents this warning:

"Note: There is no recommendation to use all of these categories. Just use those which you think make most sense to you and your local community"

Note also that sometimes it will be needed to add support for a second group when tags are not strictly organized as a pure hierarchy. we can see that in some tags that use additional categories at end of their description page: these categories are translated as well, but less visible there than in the infobox. It would be cool to add a second group.

Finally note that organizing tags in groups isnot easy: these will likely change as most tags are still not correctly sorted. In summary all statistics above will likely change to adopt a better structure. Changing tag pages or key pages is easy, but renaming categories is much more complex and requires moving all its members and redirecting them correctly. Such operations should be minimized (notably when these categories are highly populated, but it is still long to do when there's just three/fours members. And remember as well that all translated must also be checked: a single change on a category name often requires updating several dozens of pages (this does not occur for the current state of the recently created 5000 pages that are in fact speciofying groups for non-existing categories, it's not a problem of renaming categories, but still a problem to fix ALL these Tag/Key pages, independantly of the decision to this topic! — Verdy_p ^(talk) 09:50, 16 March 2017 (UTC)

Voting

I Voting for Option 5 or Option 1. Lenochod (talk) 07:19, 17 March 2017 (UTC)

Relation multipolygon and onRelation=no?

Discussion moved to Template talk:ValueDescription#Relation multipolygon and onRelation=no?

[snip] ... there is a more serious issue here: a comment on a high-profile talk page has gone unanswered for more than a day and this says that the community is losing its grip on the wiki, which needs to be answerable to the community if we are to have it at all.--Andrew (talk) 20:57, 15 May 2017 (UTC)

Where is the debate? I don't really understand why we'd discuss this here on Talk:Wiki (In general it seems we're discussing too many different things on this page) -- Harry Wood (talk) 22:31, 15 May 2017 (UTC)

The debate is in the edit comments here. I did not know where else I should raise this issue. This question is raised repeatedly and it seemed to me that we need a clear consensus on this issue for those who disagree. Chrabroš (talk) 05:37, 16 May 2017 (UTC)

You should raise the issue... well I'll do it for you.

Discussion moved to Template talk:ValueDescription#Relation multipolygon and onRelation=no?. ...and crosslinked from Talk:Tag:building=office

Please always go to the Talk page for discussion especially if you're reverting for a second time.

If you need to flag something for urgent attention of wiki admins then I suppose this page might be a place to do that, however there generally needs to be a trail of discussions forming evidence of clear demonstrable misbehaviour before any heavy blocking action would be taken. Basically... always try to have a discussion first. So head on over there now

-- Harry Wood (talk) 14:46, 21 May 2017 (UTC)

Wikibase

Hi all,
after having read this discussion (about machine-readability), and this one (about semantic wiki), this tagging mailing list thread (about tags organization, and specially this response) and after having found the interesting Taginfo/Taglists/Wiki project, what do we think about using Wikibase as a database for tags?

For example the Taglists project is really useful, but the lacking of a common database caused the not-so-stright Wiki -> Taginfo -> Wiki workflow... --NonnEmilia (talk) 21:11, 4 September 2017 (UTC)

I think it's a great idea to have a Wikibase instance for tags, to replace the current template-based content. Another possible use case for Wikibase would be content such as Template:Software that is intended to be machine-readable. Using this at the moment relies on hacks like my TTTBot (which is currently broken anyway, although that's pretty much my fault). A clean solution for this kind of semantic data, and replacing the need to manually synchronize wiki content with queries, would be amazing. While the Taginfo solution is alredy a big step forward, Wikibase seems like it could be a very good choice. --Tordanik 16:32, 7 September 2017 (UTC)

I have linked your word "Wikibase" - I hope the right target. I did not not know about this project before. --aseerel4c26 (talk) 08:00, 14 April 2018 (UTC)

I undid your edit to comment of other person. Link is Wikibase Mateusz Konieczny (talk) 04:56, 15 April 2018 (UTC)

Support as long as we don't duplicate efforts with Wikidata. Non-mission critical semantic data should be offshored to Wikidata as much as possible. Pizzaiolo (talk) 10:32, 15 April 2018 (UTC)

Support with Pizzaiolo's caveat; scope creep is to be avoided, as is duplicating the efforts another open community project. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 10:44, 15 April 2018 (UTC)

Note "However, due to complexity and dependencies, it requires some additional steps." and that Wikidata is quite hard to edit. Can you provide some examples how Wikibase would be useful, providing benefits that are larger than drawbacks? Mateusz Konieczny (talk) 15:52, 15 April 2018 (UTC)

I strongly support using structured data to organize OSM tags, assuming this is a machine-readable tag metadata effort, and not a tag storage replacement. Wikibase can be hosted here, on this wiki, alongside the rest of content, but in separate namespaces (e.g. T for tag, and V for value). A few challenges/thoughts:

• Tags are strings (e.g. "name:en"), not integers (e.g. Q42). Wikibase needs to be customized to support that - to use a string as a primary key (and corresponding foreign keys), or have a "magical" property whose whose value must be set during creation, must be unique, and can never be changed. I do not know how difficult it would be to modify Wikibase for this (see [phabricator ticket)
• Storing "enum" values: For many tags, e.g. "religion", values are not arbitrary, but rather have a list of values. These values have similar requirements as tags above, but should exist in a separate namespace. NOTE: many of the values would simply be a redirect to Wikidata, e.g. each individual religion string should be mapped to it.
• Set up query service (similar to WDQS), allowing complex lookups into that data. Sophox is a good fit here, it can import this data relatively easily using existing tools.
• Modify main editing tools (iD, JOSM) to do lookups, fetch localized descriptions, and also get value suggestions and other recommended tags.

P.S. I created a task for Wikibase to figure out the immutable keys.

--Yurik (talk) 00:33, 16 April 2018 (UTC)

update: Wikidata team suggested we use fake URLs to force uniqueness of IDs, e.g. we could store a URL back into key namespace -- https://wiki.openstreetmap.org/wiki/Key:wikidata as a sitelink, and wikibase engine won't allow multiple wikibase entries to share that same URL. We may need to customize UI, or possibly add some helper scripts to make it easier to manage. --Yurik (talk) 22:17, 22 May 2018 (UTC)

Support – and not just for tags, either. There are a lot of efforts to parse content from this wiki, including calendar entries, user groups, and apps. Reliably extracting data from MediaWiki markup is notoriously tricky, though, so a machine-readable storage for such data would be very useful. On the wiki itself, this would also alleviate the need to manually sync infobox content across all translations of a page, which is currently a major cause of duplication and errors. --Tordanik 16:39, 25 April 2018 (UTC)

@Tordanik: It might make sense to use tabular datasets for this. Wikidata is a "facts" database, and it doesn't work very well for blobs of data. See here. --Yurik (talk) 17:05, 25 April 2018 (UTC)

Most of my examples would involve moving content that's currently in infoboxes (e.g. Template:User group or Template:Software to Wikibase. This is very similar to what I'm seeing done with Wikidata. --Tordanik 22:12, 25 April 2018 (UTC)

@Tordanik: sure, that's a good usecase for Wikidata, not datasets. I wonder how difficult it would be to set up wikibase for multiple namespaces - because we wouldn't want to store tags and "free form" data in the same place, or it would quickly get very confusing. --Yurik (talk) 22:17, 25 April 2018 (UTC)

note: Wikibase is not just meant to be used to query Wikidata. Other databases may be queried as well, including custom datastores (which could be hosted on this wiki in "files", or in or JSON pages (this wiki supports the JSON content model which can be used on any namespace). Newer versions of Mediawiki allow attaching any page with a custom CSS stylesheet as well. And with some security settings, you can also attach custom javascript (this is currently enabled only in "User:" namespace but they are read as executable scripts only when the user is connected to their own account on this wiki and where the Javascript is stored in his own user pages, and only provided that these pages are protected from editing by other people than the user himself. But we could have a javascript framework used on this wiki exposing a limited set of javascript and limited set of DOM API (for now this isolation framework is still not developed, so we still rely on wiki admins to install other CSS/Javascript in this wiki; and most addons used on Wikipedia and activable in their preferences are not usable on this wiki, as they still depend on core extensions not installed, notable Scribunto/Lua and Wikibase). — Verdy_p ^(talk) 15:51, 24 May 2018 (UTC)

Update: I have created a page outlining this proposal, and I have also gained access to an older version on the OSM Wiki, with which I will be experimenting. Please comment or update that page with details, e.g. how you would want to structure metadata, what properties we would need, etc. OpenStreetMap:Wikibase.
CC: @Aseerel4c26:, @Mateusz Konieczny:, @NonnEmilia:, @Pigsonthewing:, @Pizzaiolo:, @Tordanik:, @Verdy p:.
--Yurik (talk) 23:06, 16 August 2018 (UTC)

There is now a demo site with the copy of the current wiki, and a Wikibase setup with a few examples. --Yurik (talk) 16:25, 20 August 2018 (UTC)

Thanks, looks great. I will comment on the page then... U30303020 (talk) 20:17, 20 August 2018 (UTC)

Enabled in a read-only mode. Most frequent keys already imported, so Lua scripts can already be written to use that data. ReadWrite will be enabled shortly. See updated OpenStreetMap:Wikibase --Yurik (talk) 05:42, 18 September 2018 (UTC)

Exciting stuff! One big thing I'm missing is a link to Wikidata. For instance, Item:Q104 should somehow link to w:d:Q787417, either with a sitelink or a dedicated property. Looking forward to playing around with this. Pizzaiolo (talk) 09:47, 18 September 2018 (UTC)

Amazing! Exactly what I was thinking! Thank you all! --NonnEmilia (talk) 14:28, 21 September 2018 (UTC)

Use Listeria

Hi, Can we use listeria in wiki for generating lists ? @Yurik: Is it possible Sophox help in creating list like Districts in Andhra Pradesh ? Something similar to [5]

Using templates similar to

https://www.wikidata.org/wiki/Template:Wikidata_list

https://www.wikidata.org/wiki/Template:Wikidata_list_end

-- 04:18, 5 May 2018 (UTC) —Preceding unsigned comment added by Naveenpf (talk • contribs)

@Naveenpf: sure, it would make perfect sense to run Listeria from Sophox - the same technology, just a bigger dataset. Moreover, I wonder if the maintainer of Listeria could run it on this wiki too? Should be fairly trivial, as the wiki tech is the same as well :) --Yurik (talk) 04:25, 5 May 2018 (UTC)

<pre> and <code> should be LTR inside RTL context

Because the content of <pre> and <code> tags is almost always a piece of code or sth similar, then it need to be LTR and Left-Aligned.

Currently in Persian pages we need to explicitly add some css tags to adjust them.

for example, this is a Persian context which is RTL with a sample code:

این یک متن آزمایشی است. در زیر قطعه‌کدی را مشاهده می‌کنید:

<html>
<body>
hello!
</body>
</html>

This is the same content. Here I used some css styles to adjust the display:

این یک متن آزمایشی است. در زیر قطعه‌کدی را مشاهده می‌کنید:

<html>
<body>
hello!
</body>
</html>

This is not specific to this wiki. Note that the "pre" or "code" HTRML tags do not imply that the content is in English or Latin, they can as well contain plain Arabic text. But to change back to LTR in a RTL context, there's a better choice than long styles: Mediawiki predefines a class name (the effective styles are more complex than just direction and text-align styles, , there's also the behavior of margins, paddings, mirroring for graphics, directions for arrows, and there are rules about how these styles are inherited. Look at Template:Ar to see the class needed for correct inheritance.

Does it mean that the correct way to include LTR in RTL context is to close the RTL block just before the LTR content and at the end of it start another RTL block? like this:

این یک متن آزمایشی است. در زیر قطعه‌کدی را مشاهده می‌کنید:

<html>
<body>
hello!
</body>
</html>

این یک متن آزمایشی است. در بالا قطعه‌کدی را مشاهده می‌کنید:

Normally the example above is an inclusion within an unbroken sequence of Persian text, so you should not close ot and reopen it. Instead you should isolate the LTR inclusion, by effectively adding style or class to the "pre" block, where this switches to a non-Persian context which itself is isolable. Changing the direction and alignment is not enough, there should be a language tagging as well (this has en effect on the rendered font, as well as on semantic parsing for search engines, or for an automatic translator component used in browsers to make the proper guess): The Template:Fa (or Template:He, Template:Ar, Template:Ur, Template:Dv) does does both styles/class plus language tagging, and correctly uses the isolation mechanism; it also somrtimes tweaks a bit the fonts sizes rendered at typical resolution (because the default fize on the wiki is smaller than normal and only tuned for Latin, making Arabic difficult to read, so the font size should be inverted; some scripts also are tuned to use a wider line-height than the default 1.6 value, but HTML PRE blocks use a smaller line-height) ! — Verdy_p ^(talk) 13:21, 13 June 2018 (UTC)

So I created a template for LTR inclusion: Template:Ltr.

این یک متن آزمایشی است. در زیر قطعه‌کدی را مشاهده می‌کنید:

<html>
<body>
hello!
</body>
</html>

این یک متن آزمایشی است. در بالا قطعه‌کدی را مشاهده می‌کنید.

What's your opinion? iriman (talk) 15:31, 14 June 2018 (UTC)

That's the correct way to do that. Note that when you place a {{Fa}} template at top of a Persian page (named "Fa:*") you place it just after the {{Languages|Untranslated English title}} template, but you are not required to close it with a </div> at end of page, because it is closed there implicitly by Mediawiki: this will ensloe the whole page in Persian. Then there you can use "{{Ltr}}Some block in English</div>" in the middle of the page to enclose vertical English blocks, or {{Ltr|some text in English}} to enclose inline English text this avoids mirroring or reordering problems within the English extract embedded in an RTL paragraph.

The only problem I see with "{{Ltr}}" is that it implies that what is inside is in English; you may use it for embedding other Latin-written languages but there's no optional "lang=*" parameter to override the "lang=en" which is generated. I think we could add it. — Verdy_p ^(talk) 04:16, 16 June 2018 (UTC)

What if we use {{En}} instead of {{Ltr}} and update the template of other LTR languages to work simillar to {{Ltr}}?

You seem to have found why: {{En}} is already used for something else (adding an annotation on an non-English page after a link that the target is for now in English (and possibly not available in the language of the current page: this may be checked in order to replace the link target and then only remove the {{En}} inclusion). The {{En}} template (it has also several other aliases) is used since long on many pages of this wiki.

Yes this may seem a bit insconsistant but not dramatic, and there's no emergency to fix that. In pagew with RTL language, using {{Ltr}} is almost always to include untranslatable technical elements or code in English, I think it will be exceptional if this ever refers to another LTR language and for now there's not ben any need for it (this may change later if there's a new goal to simplify some large maintenance, and in that case we can still create a cleanup task as there will be many edits to do before applying the change. For now simplicy is favored when it covers most practical cases (for the other exceptional cases, we can do them without using any template, or by setting an optional "lang=*" parameter to {{Ltr}} to override this default "lang=en" value). — Verdy_p ^(talk) 19:18, 25 June 2018 (UTC)

Yes, it's an extra effort that is not needed yet. thanks for your kind help. -- iriman (talk) 11:52, 27 June 2018 (UTC)

Direction of preview for section editing in RTL mode

Could we force the section-preview to follow the main article direction? This is a problem for rtl pages.

For example this is a RTL page with some sections. Edit one section and see its preview. It's LTR. Temporary putting a rtl template like {{Fa}} at beginning could solve the problem but this is not a good solution. -- iriman (talk) 14:10, 27 June 2018 (UTC)

Unfortunately not, because this MediaWiki version does not have builtin support for editing with user preferences. A user can select that his prefered language (for the generic UI) is another locale than English by default, but we cannot even access this info from MediaWiki itsel or its API or via templates. The geenric CSS also would require some more work to disintguish cases (the only stable thing we can use is the builtin "mw-content-rtl" class used noramlly for the general UI and that we can reuse for the content. But most javascripts installed on this wiki and most CSS is still not tuned for that. The wiki editor also lacks a button to easily switch the editing direction of the form input box.

Various extensions found in Wikipedia are not installed on this wiki which is still basically tuned for English only (and there's no real support for now for the "Translate" extension of Mediawiki, and no realiable way to detect the language of the page. We had to find solutions (note that this wiki started to use since long a different solution for naming pages, using "lang:" prefixes for pages (initially this was done for 7 languages only using namespaces, but only for the article space and their associated toalk page, this solution was not used for all other languages because it would have required to create hundreds of namespaces, and there's a limit on this. Wikipedia or Wikimedia Commons or Wikimedia MetaWiki does not use these namespaces but use another convention using "/langcode" suffixes in page names instead of "langcode:" prefixes/namespaces). The current development of Mediawiki still does not support support the convention that was created many years ago on this wiki. It also does not have anyway to instruct the parser (with a builtin keyword, or some tuning on pagename detection applicable to one or several existing namespaces, and differently for the 7 languages that currently have dedicated namespaces) that the base content of the page is in another language than English, so we have to mark the wiki content of the page itself with explicit tagging. This is tricky to resolve and the only solution would require installing some custom javascript and CSS in the generic stylesheet of the whole wiki. This would require administrator privileges, but existing adminsitrators of this wiki are unable to do that (and they did not ask for help by asking to some Wikipedia admins for help, apparently OSM wants to keep its adminsitrative independance from Wikimedia).

Making this wiki international is then a long and difficult effort, which has to take into account the existing technical limitations.

And even if the wiki is supposed to allow the new VisualEditor, it is not working on this wiki. — Verdy_p ^(talk) 14:56, 27 June 2018 (UTC)

Thanks for this long explanation! Currently after enabling page content language feature on this wiki, the concern about language of base content is resolved. Also I'm so pleased to tell that the primary topic of this section is solved, too! iriman (talk) 21:23, 15 June 2019 (UTC)

Rewriting Template:Relation

I would like to crosspost my blog entry here which can be found at https://www.openstreetmap.org/user/Tigerfell/diary/44901. Please speak up, if you have any suggestions or questions. Otherwise, I will just continue with this in about a week to assure enough time for discussion etc. Thanks --Tigerfell  (Let's talk) 17:17, 6 September 2018 (UTC)

Ok, final draft done. Please comment! Code and documentation can be found at Module:Sandbox/Tigerfell. --Tigerfell  (Let's talk)

Thanks a lot for your efforts! It's a very well documented change.

If I were looking for something to nitpick, then I might suggest using the term "id" for an OSM element's numeric identifier – it's a more standard term than "number"/"no". (The variable name "relationNo" made me think of a yes/no distinction at first.) But that's really scraping the bottom of the barrel in terms of criticism. ;) As far as I'm concerned, please go ahead! --Tordanik 15:12, 27 September 2018 (UTC)

Thanks for the feedback. As this seemed to become some kind of mass edit and I lack the experience of that I just wanted to include other opinions if possible. In addition, I wanted no roll backs later on. I will change that. --Tigerfell  (Let's talk) 22:05, 27 September 2018 (UTC)

Rewriting Template:Node, Template:Way, and Template:Area and proposed automated edit

Following my previous change of Template:Relation, I would like to align the appearance of these templates with it. I am planning to change the templates in a way that they use partially the same Lua code as Template:Relation. I would therefore propose to drop the same features as in the relation template.

As there were some pages that used the option to not specify a relation number and I am planning to drop this feature from the other templates as well, I would like to request a community approval for an automated change that replaces these template calls with static text which was shown in the old version. The full request is available at User:TigerfellBot. --Tigerfell  (Let's talk) 18:27, 3 October 2018 (UTC)

Like last time, there is a final draft at Module:Sandbox/Tigerfell. Please comment if interested. --Tigerfell  (Let's talk) 12:50, 5 October 2018 (UTC)

Roll back {{Languages}} template?

The version of the {{Languages}} template and its associated templates including {{Languages/div}}, {{LanguageLink}} and {{Available languages}} from September 2016 has several advantages over the current version:

1. The implicit syntax ({{languages}} on its own) worked for all pages unless, like Uk:Об'єкти мапи the page name is different from English. It no longer works for pages (such as Map Features templates) with a colon as part of the page name, but only in some languages.
2. The pages were automatically sorted in categories by the name without language prefix (with the ability to override if needed). This no longer works.
3. When viewing pages in mobile mode the languages that a page is not translated into only flashed up once when the script and style sheet first loaded. They now flash up every time.
4. A large number of languages not used on this wiki such as Sanskrit have been added to the template, this means that the box takes up the whole screen on mobile devices while the red links flash up and you have to wait until you can read the page.
5. The 2016 template always accessed the {{Langcode}} template without arguments where Mediawiki only evaluates it once. The current version uses the {{langcode|{{{lang|}}}}} syntax which stops large pages rendering by repeated evaluation.

I am therefore proposing reverting the whole set of templates to September 2016.

As a matter of conflict of interest I was the one who created the September 2016 pages.

--Andrew (talk) 07:06, 23 September 2018 (UTC)

Just an idea, that might actually be far more performant and flexible compared to the current template solution: store all translated pages in Wikibase. I created one such item by hand just to see what it would look like: Item:Q104#P31 -- using this data, we can generate a list of available translations with a very quick Lua script. PROs: translation template is very quick to generate, 3rd party software/bots/tool sites can easily find all available translations of a subject. CONs: a new translation has to be added to the data item (can be solved with a simple bot). --Yurik (talk) 22:38, 5 October 2018 (UTC)

Unfortunately it seems all consequent edits were to the garbage. We all have to do them again? This is just one made now: removing pt-br since it was merged in pt, or we would see people creating again pages in "pt-br". That was already made by another user in 2016! Zermes (talk) 14:43, 6 December 2018 (UTC)

That is good to know. I did not know that the merge was final and complete. If that is the case, I would suggest merging the last pages and templates. Maybe, you should also update the table at Wiki_Translation#OSM_Wiki_language_codes and add a note below. (Sorry for posting this slightly off-topic comment.) --Tigerfell  (Let's talk) 17:32, 6 December 2018 (UTC)

New Wikibase-based KeyDescription and ValueDescription templates

The new version of the {{KeyDescription/Sandbox}} and {{ValueDescription/Sandbox}} templates (infoboxes) are ready for review. They work as before, except that if some parameter is not given, it will be taken from the corresponding wikibase item. So far, it supports: description, image, elements (onWay/onNode/...), groups, and statuses. In some cases it will highlight if the parameter is different from the item - this way it will be easy to keep them in sync until we can safely remove them from the wiki pages. Also, for the ValueDescription, if the wikibase item does not have status or onWay/onNode/..., it will automatically take those values from the corresponding Key item. Lastly, if the item defines that certain value is restricted to just some region, e.g. noexit=yes should not be used on ways in DE-speaking regions, the infobox will still be properly shown depending on the language. Let me know what you think. --Yurik (talk) 08:51, 29 September 2018 (UTC)

Today I finished migrating {{KeyDescription}} template to use the new Wikibase items. It should function transparently to everyone. The only noticable change is the small gray pencil icon next to the description - lets users quickly edit the corresponding item. Note that if description mismatches between the item and the wiki page, it will show two pencils - a red one to edit wiki page, and a gray one for the item. Please make them the same, and it the red pencil will disappear. All such mismatches are tracked with various categories, e.g. Category:Mismatched description. Please let me know if anything breaks. --Yurik (talk) 00:02, 6 December 2018 (UTC)

Great to hear that. I was looking forward seeing this in action. Is there any way we can avoid having two short descriptions one in the template one in WikiBase in the long run? --Tigerfell  (Let's talk) 17:14, 6 December 2018 (UTC)

Of course, you can simply delete absolutely all template parameters , and it will use data directly from the data items. The problem is that taginfo currently parses wikimarkup to get those parameters, so it needs to be updated. --Yurik (talk) 17:37, 6 December 2018 (UTC)

Please update the documentation of the changed templates accordingly! I would suggest you also add an ambox to all translations. In addition, I would like to know how you suggest to change the Proposal process. I already started a threat there, Talk:Proposal process#Changes after the installation of Wikibase. Thank you. --Tigerfell  (Let's talk) 15:54, 9 December 2018 (UTC)

Tigerfell, I agree that we should change it, but currently there is very little change needed just yet - not until taginfo starts using data items directly. Without it, we are forced to continue using all of the existing template parameters for everything, or else taginfo will show no documentation for any of the tags. I will add a few sentences at the top, with the expectation that eventually many (all?) template params will be gone. Thx for the heads up about the proposals. --Yurik (talk) 16:12, 9 December 2018 (UTC)

Optimizing wiki templates

There is a magical command to see the performance of each page: mw.config.get('wgPageParseReport') (ran from the browser debugging tools page), or more specifically console.table(mw.config.get('wgPageParseReport').limitreport.timingprofile), which shows the top ten slowest templates used on the page. For example, the main page shows 53.23% 1377.800 922 Template:Langcode as the top offender. Key:name -- 93.36% 2951.955 1 Template:KeyDescription, etc. Yet, I think it is the {{Langcode}} that ends up causing the most slowdowns, and may need to be rewritten. Just a few observations to make the wiki faster. --Yurik (talk) 17:36, 5 October 2018 (UTC)

That is interesting. Where can I find this debugging tools page? I currently render more of less randomly pages using preview functionality if I want to see the performance of my templates.

Regarding the Langcode template, please see #Roll_back_.7B.7BLanguages.7D.7D_template.3F further up. --Tigerfell  (Let's talk) 17:58, 5 October 2018 (UTC)

Debugging tools is part of your browser. E.g. in chrome, click the menu (triple dot), more tools, developer tools, switch to console, enter commands. --Yurik (talk) 21:19, 5 October 2018 (UTC)

Map extensions

This wiki currently features two extensions for displaying maps (Simple image MediaWiki Extension and Slippy Map MediaWiki Extension). Simple image extension currently suffers some problems regarding the limitations of the service and the lack of HTTPS support. Slippy Map extension has some issues as well and is marked as depreciated since 2013 [6].

That is why I suggest installing an new extension to this wiki. It would gradually replace the current ones or could be used as a backup if the others work irregularly. Reading through the repositories and MediaWiki_extension#Ideas_for_improvements I came up with the following requirements regarding such an extension:

1. Dependencies towards a singular website should be avoided (see issues with Simple image extension).
2. No direct dependency towards OpenStreetMap tile servers (puts loads directly on the servers).
3. No extensions that require an arbitrary amount of maintenance or self-coding (missing coding/maintenance capacities in the wiki).

I found two suggestions at MediaWiki_extension#Suggested_map_extensions, Kartographer and Maps. Both seem reasonable to me, but certainly a more detailed check is necessary. Any suggestions/comments? --Tigerfell  (Let's talk) 11:01, 6 October 2018 (UTC)

Disagreement with point 2: if we can't serve our own tiles in our Wiki, we're doing something wrong. Mmd (talk) 11:31, 6 October 2018 (UTC)

Point 2 refers to the first version of the MediaWiki extension article written by Harry Wood. It reads:

A straightforward reference to openstreetmap.org within an <IMG> tag is probably not satisfactory because (A) This would put server load on OSM for wikipedia's traffic (B) OSM's dev server goes down, the wikipedia articles get screwed up (C) OSM's dev machine runs slowly, wikipedia articles load slowly.

But I guess it makes the search very narrow... When questioned whether I would rather put load on the OSM server or a dependency on a singular website with no direct affiliation to OSM or no high interest in this service (like staticmaps.openstreetmap.de), I would choose the first option. Well, maybe you are right. @Harry Wood: might be able to say something about this? --Tigerfell  (Let's talk) 19:49, 6 October 2018 (UTC)

Aren't these objections specifically about Wikipedia (as opposed to wiki.osm.org) depending on OSM's tile servers? I don't think this would restrict the choice of extensions for our own wiki. --Tordanik 08:28, 10 October 2018 (UTC)

Yes. That's talking about use on other wikis and (the ambition that time was) on wikipedia. So not really relevant although it probably relates to part of the reason Firefishy decided to quickly label that repo as "deprecated": discourage anyone installing the code on other wikis. -- Harry Wood (talk) 09:54, 10 October 2018 (UTC)

Y Ok, then we can drop point 2. --Tigerfell  (Let's talk) 18:23, 10 October 2018 (UTC)

If users select maps with google as service will it be charged? Admins will have to look that frequently. Does Maps extension supports Wikimedia Maps ?. One advantage of Wikimedia Maps is that multilingual support is there. Plus the support for wikidata queries -- Naveenpf (talk) 12:04, 6 October 2018 (UTC)

As far as I can see, it is possible to specify the available mapping services in a file: JeroenDeDauw/Maps/blob/master/Maps_Settings.php#L15 ^GitHub. I would limit that to leaflet as we do not need the other services. There is no way to get charged if not API key is provided (the map would not be displayed however). As far as I can see, Maps extension does not support Wikimedia Maps. It has some querying functionality using Nominatim for instance [7].

Those are surely an advantages, not to mention that Yurik who is one of the authors is also a wiki admin here. The maps are rendered by Wikimedia Foundation and we would have to accept their Maps Terms of Use. --Tigerfell  (Let's talk) 19:49, 6 October 2018 (UTC)

My strong request would be to be able to continue to select from among various layers in slippymap directives, like layer=transport or layer=cycle. I can do that now (and do in many wikis I've written, example1, example2) and I want to see those (or something like them) continue. Rail and biking are very important to my mapping and wiki-writing here in the USA (I've spoken at SOTM-US conferences on each, in 2016 and 2014). Yes, there is a watermark stamped across the front of each such map "API Key Required" and I can live with that. To be very clear: both of these layer directives WORK TODAY and while slippymap is said to be "deprecated," part of the definition in my dictionary for that word includes "typically due to having been superseded." It does not appear that slippymap HAS been superseded and if this discussion is about fixing that, OK, fine. But if I find that capability disappearing with no good alternative, I will be upset that we are destroying working (or very nearly working) wiki functionality. Anybody would be upset with that. Let's not make ourselves upset, please. Stevea (talk) 08:25, 10 October 2018 (UTC)

Well, currently this is the only extension displaying a map. As I understand Harry, it is not maintained. I fear that there will be a day when it does not work any more (because it is not maintained and the wiki software needs to be updated for safety reasons). Currently not installed Maps extension seems to me a good precaution as I do not want to have a broken wiki either. Could you have a look and say if it satisfies your needs? It looked ok to me, but I might have missed something. --Tigerfell  (Let's talk) 18:23, 10 October 2018 (UTC)

The current situation is... the SlippyMap extension works OK-ish, but could be improved. From a code point of view it's quite a mess. Not following modern mediawiki extension code layout/conventions. Developing it may be a bit of dead-end (hence "deprecated") because really the way to improve it would be to ditch it and switch this wiki to use a more fully featured well developed extension. There are a few, but we'd need to investigate and find one which has a "no support for google maps" config. Supported wikitext syntax would also be an issue.

The StaticMap extension is the one which is actually broken at the moment, because StaticMapsLite service is broken, so this needs more urgent attention. Other than people annoyingly failing to keep services running, I feel this extension is kind of OK actually. It doesn't really need to be more fully featured (although it's also not following MediaWiki conventions). Not sure which repo that extension is getting fetched from these days. Is it also labelled as "deprecated"? Probably

-- Harry Wood (talk) 10:01, 10 October 2018 (UTC)

Regarding the operations of the SlippyMap extension, right now there is no option to have two maps on one wiki page (StaticMap broken, SlippyMap cannot deal with that). Talking of switching to a well-developed extension, Maps seems reasonable in that case. As already pointed out, it is possible to disable Google Maps support. In addition, many renderings can be displayed (including the currently available ones). Please have a look at the configuration files (link above). The extension uses a different syntax: {{display: ... }}.

The current situation regarding StaticMap extension was the cause for writing point 1: Dependencies towards a singular website should be avoided. Apparently (I can not confirm that), the extension works, but the map providing service does not and it sounds to me as if this will take some time. Therefore, a more than OK-ish working map option would be desirable for me. I acknowledge that replacing StaticMap extension with some slippy map is not a go ahead. --Tigerfell  (Let's talk) 18:23, 10 October 2018 (UTC)

I agree with Harry that "the SlippyMap extension works OK-ish..." as IMO it does (except for the API watermark). It is not a major limitation (for me) that I can't display more than one slippymap on a wiki page, but I'm guessing that's a problem for others. Tigerfell, while it is wise to look to a future where if (because of a yet-to-exist security threat?) updating wiki architecture wholesale breaks an existing extension (like SlippyMap) I'm not sure that "fearing" that day (living one's wiki life in fear?) is a healthy motivating factor. Still, I recognize that SlippyMap is code its author calls "quite a mess" and "not following modern...conventions." I don't quite understand what is meant by "supported wikitext syntax would also be an issue" but as "an issue," it seems it could be worked out. Although, the direction to go in the direction of Maps seems "healthier" for OSM's wiki future: it's more modern, maintainable code, though "it also doesn't follow MediaWiki conventions" causes me some concern that we'll go through this entire exercise again someday.

Yes, it appears (from the Gallery and User Documentation glances I gave them) that Maps is a suitable substitute which might one day supersede SlippyMap, so again I agree with Harry. But as it is not installed here, I can't give it the "QA Test Drive" I would like to so I may fully answer that. It looks like a richer and more modern version of what we now have, so for those reasons I would support a migration towards integrating it. However, I do not understand fully the technical issues, except that "people annoyingly fail to keep services running." (I am especially enamored of the "disable Google Maps support" feature, good for that capability, good for OSM for flipping that switch On if/as we install it). Perhaps this is pie-in-the-sky of me (pleasant to contemplate, very unlikely to be realized) but it seems WE (OSM, somewhere, somehow) can be those "who keep services running." Much about how all the pieces work together is opaque to me (I'm learning), though as has been said earlier, "if we can't serve our own map tiles in our wiki, we're doing something wrong." Stevea (talk) 19:29, 10 October 2018 (UTC)

I added a request at openstreetmap/operations/issues/249 ^GitHub. --Tigerfell  (Let's talk) 22:11, 13 October 2018 (UTC)

N Unfortunately, this had to be ruled out as the Maps extension requires the installation of 'Composer'. --Tigerfell  (Let's talk) 12:15, 15 October 2018 (UTC)

After this rather not so successful action I would suggest taking following steps. If one fails I would continue with the next.

1. examining if Kartographer extension works with maps from our tile servers
2. requesting if Maps extension can be altered to drop the necessity of using composer.
3. changing SlippyMap extension

Any suggestions, comments? --Tigerfell  (Let's talk) 11:17, 22 October 2018 (UTC)

Now I found MultiMaps extension. Looks okay to me, but we would have to check if/how to use tiles from different URLs (like Bicycle layer vs. Mapnik) and their support integration with Composer. Commercial layers can be disabled. --Tigerfell  (Let's talk) 08:20, 16 November 2018 (UTC)

I think should try Kartographer extension . -- Naveenpf (talk) 13:44, 14 August 2019 (UTC)

MultiMaps extension is available in this wiki for about two months now. The only thing that keeps me from changing the old style slippy maps is the fact that the currently installed version 0.7.2 does not display Transport Map tiles and for compatibility reasons the system administrators do not want to install version 0.7.3 which was tested on MediaWiki >1.33.x (newest "pre-release") while we are running 1.31. So, we are essentially waiting for a new MediaWiki release. Meanwhile, I listed all the options for displaying maps (except for the old extension) at Wiki:Maps.

Or are you looking for features that MultiMaps does not offer? --Tigerfell  (Let's talk) 18:51, 14 August 2019 (UTC)

Hello tigerfell, we are mapping admin boundaries. if we have kartographer we can include here or https://en.wikipedia.org/wiki/User:Naveenpf/sandbox#Districts_in_India -- Naveenpf (talk) 00:32, 15 August 2019 (UTC)

How many maps do you want to create? If it is just a few it is maybe easier to take a screenshot? Unfortunately, I have not found any option for changing the map style to OSM Carto and I think it might be confusing to have a different style for the wiki maps. --Tigerfell  (Let's talk) 16:00, 15 August 2019 (UTC)

Lua errors with empty BrowseRelation value

I'm still not exactly sure how all the moving parts work together, and this might be a better communication channel to discuss this.

It appears that because of the way that our wiki's Relation code (Lua script?) works (specifically the BrowseRelation function), a blurb of wiki markup text of two open curly braces followed by BrowseRelation then a vertical bar then two close curly braces (note the empty value after the vertical bar) USED TO return a polite warning of Relation not defined yet. Now, it returns a clickable link with larger-type red text:

Lua error in Module:Element at line 11: Given relation number parameter is not a number.

While true (it ISN'T a number, it is simply empty), it sure would be nice if the "old behavior" of Relation not defined yet were to return to OSM's wiki. Clicking the link shows a backtrace erring in function "chunk."

An example is at https://wiki.openstreetmap.org/wiki/Colorado/Railroads#Utah_Railway_.28UTAH.29

In short, "recent changes for apparent improvements have broken something." Perhaps it will remain broken for the sake of the apparent improvements, perhaps it can be patched/fixed/improved so the original behavior (supporting a certain imperfect syntax, I agree) returns and massive amounts of existing wiki don't have to be modified to back-fix for the sake of the "apparent improvements."

Thank you. Stevea (talk) 14:07, 9 October 2018 (UTC)

{{BrowseRelation}} links to {{Relation}}, so please have a look at this template's documentation.

If you have any questions regarding the change of this, please ask them here or at the template's talk page.

This behaviour will be simulated for the existing pages by changing the wikitext in an automatted process. This is described at Task 'Undefined Elements'. The fact that this takes a while to change is mostly due to the Automated Edits Code of Conduct. --Tigerfell  (Let's talk) 18:36, 9 October 2018 (UTC)

This Wiki need a better refresh new image configuration

(bugtrack here?)

Hi. This Wiki is used for software documentation, software use guidelines, etc. and we need illustrations...

A good illustration wiki interface need fast response, so there are a kind of bug: the Wiki (nowadays) is waiting a lot of time to change illustration. As users, we need to wait less (seconds not half hour or hours) to see our changes. --Krauss (talk) 14:20, 12 October 2018 (UTC)
PS: it is not brower cache, and tested many times.

Could you name an example case, so someone can look at this specific image case? Thanks! --Tigerfell  (Let's talk) 11:37, 15 October 2018 (UTC)

Hi @Tigerfell:, when I updated File:UMLclassOf-osm2pgsql-schema.png, the page Osm2pgsql/schema not updated. --Krauss (talk) 22:35, 15 October 2018 (UTC)

Sorry, I forgot to answer. It sounds to me as this is an "issue" with the MediaWiki software. When updating templates for instance, it adds all pages that need changes to a waiting queue and works on them with some delay. If the server load is not arbitrary high, one can "purge" a page, forcing the server to render the most current version. Does that work? --Tigerfell  (Let's talk) 09:57, 22 October 2018 (UTC)

After facing the problems myself, I figured out that it helps in my situation to dismiss the browser cache, because otherwise it still uses the old images. --Tigerfell  (Let's talk) 17:00, 26 January 2019 (UTC)

Installation instructions for Maps

I updated MediaWiki to version 1.31 after 5 years. Since SimpleMap is not maintained anymore, I had to look for a replacement. After hours of searching I finally found that there are cartographers and maps running on the current version of MediaWiki. At the moment I am using cartographers, but I want to install maps because of the variety of possibilities. I came up to the installation of the composer. After that I failed with the installation instructions, which are available in the MediaWiki.

Question: Is there an installation guide in the OSM section that helps me here? (Bks29) 5:30, 22 October 2018

Hello again. We do not use "Maps" extensions because the composer (which is required) does not work with our technical setup (see current end of section #Map extensions, the red cross indicates failure). You can view a list of all currently installed extensions in this wiki at Special:Version --Tigerfell  (Let's talk) 08:50, 22 October 2018 (UTC)

No problem? Please wiki-community, a declaration of agree

Hi, our community is working on contract models (CMs), examples CM/pt/BR/004, CM/pt/BR, CM/pt... No problem?

We are building a "namespace infrastructure" from CM and a first draft of contract model redaction process and foundations... Perhaps in 2019 we have good local-results and a good proposal for all other OSM-communities.

So (sorry my English), to go forward in our local-OSM-community work, and not being exposed to a risk of your "PLEASE DELETE-ALL" or similar thing, we need your "declaration of agree". --Krauss (talk) 22:55, 1 November 2018 (UTC)

Hi, I do not have the power to allow or disallow anything in this wiki. I can just speak from the perspective of an ordinary user.

To me your idea seems to be "okay", because it is related to OSM. The naming however seems to be a bit overcomplicated. I would suggest something like Pt:Contract models/BR/A. B.-School.

If the page is in Portuguese, it should be located at Pt:... or Pt-br:... (I do not know which one you currently use). These prefixes work fine with current templates which do automatic translation. In addition, I would propose Contract models instead of CM because I think that abbreviations in page titles are confusing and it would be consistent with Proposed features/.... I am not a fan of numbering pages and would use the name of the addressee instead. --Tigerfell  (Let's talk) 20:40, 5 November 2018 (UTC)

Thanks @Tigerfell:, if seems "okay" for all, we will continue/expand the proposal with more Contract Models.
About naming: it is not "bit overcomplicated" if you see it as a short label (them complicated will be a ugly long=long name).
Any document ID as a book or scientific article have a public ID: books use ISBN, articles use DOI, legislation use ELI and collections of articles (journals) use ISSN... All are short, we love short ID, not big ID.
And at this Wiki is easy to redirect the ID into expanded name, for example CM/pt/BR/004 is automatically expanded to
"CM/pt/BR/004 - Comunicado para faculdades", see the link CM/pt/BR/004.
--Krauss (talk) 20:08, 14 November 2018 (UTC)

I have the following problem with IDs as page names: If you look at a category (like: Category:Labelled for deletion), you see the page names only. You can not check for a topic to be in this category, if the page name does not mention the topic. All pages in this wiki have a page ID anyway (e.g. 1907 for this page, see MediaWiki handbook). In addition, we also have Template:Shortcut, which could be used. I have never used it, though.

As a compromise, I would suggest to name the pages something like Pt:CM/BR/004 - Comunicade para faculdades. Would that be okay for everyone? --Tigerfell  (Let's talk) 08:42, 16 November 2018 (UTC)

I would try to gather some opinions on the osm-talk mailing list, hope someone there speaks Portugese. RicoZ (talk) 20:33, 6 November 2018 (UTC)

Thanks @RicoZ:. There are a lot of lists at osm-talk, do you suggest some specific for discuss Contract Models? For Brazilian jurisdiction contract-models we use talk-BR.

When searching the wiki, I found some pages referring to such contracts already. You might want to add them to your schema (?):

• Permissions - a country-specific documentation of obtained permissions mostly for data imports
• Import/GettingPermission - containing three templates for letters like yours
• Category:Import - a category containing further possibly relevant pages

--Tigerfell  (Let's talk) 15:29, 7 November 2018 (UTC)

Thanks @Tigerfell:, I will use it in the text step, and perhaps we can unify all at CM namespace... Specifically English permissions, the main ones was consolidated by OSMF at https://wiki.osmfoundation.org/wiki/Licence/Waiver_and_Permission_Templates
--Krauss (talk) 20:08, 14 November 2018 (UTC)

Formatting pages with historic content

Some pages in this wiki describe historical services or components and may be worth keeping in order to document the history of OSM. In order to mark such pages clearly and similarly I created a draft page which I would later transform into a template. I would also propose to name a category "Historical artefacts" and categorise the articles there. Comments? Suggestions? --Tigerfell  (Let's talk) 21:02, 14 December 2018 (UTC)

The two templates {{Historic artifact start}} and {{Historic artifact end}} do the job now. --Tigerfell  (Let's talk) 14:10, 23 January 2019 (UTC)

MediaWiki "Thanks" extension

I like the Thanks extension and would be happy to see it rolled out to the OSM wiki. See the image for what it does. This may all seem a bit silly, but let me explain:

I have quite a lot of pages on my watchlist and reguarly check the recent changes. I actually like most of the changes I see. However, the contributors making those changes never learn that someone saw and appreciated their efforts. Instead, the only time people tend to actually contact other contributors is when they criticise and/or revert their contributions. This plugin offers an easy way to say "Hey, I like your edits!" every now and then, and hopefully balance out the negativity a bit. --Tordanik 20:34, 14 January 2019 (UTC)

I have also been thinking that it would benefit the wiki editing dynamics. I do not know what's involved tbh, but I think it should be fairly easy to set it up.--Yurik (talk) 22:59, 14 January 2019 (UTC)

I would also appreciate it. Technically, this depends on the w:mw:Extension:Echo which is used for the messaging, and there might be problems in case on of these extensions needs w:mw:Composer, because this might interfere with the wiki server configuration management "Chef". "Composer" wants to 'update' libraries and creates additional files for that, which in turn get stuck in "Chef" which builds the settings files based on files, "Composer" previously changed. I do not really have time to check this now, but this should not stop you if you want to add it now. Otherwise, I can take a look in about a week or Yurik just creates a pull request to openstreetmap/operations ^GitHub. --Tigerfell  (Let's talk) 00:00, 18 January 2019 (UTC)

Someone opened an issue and I commented on it today. openstreetmap/operations/issues/265 ^GitHub --Tigerfell  (Let's talk) 11:48, 23 January 2019 (UTC)

 Done in openstreetmap/chef/commit/ceab552534e0b204ce2eecd05584603d0ad23cfc ^GitHub. --Tigerfell  (Let's talk) 16:57, 26 January 2019 (UTC)

Thanks for Thanks. ;^) By the way, this issue proposes implementing something similar for osm.org. – Minh Nguyễn ^💬 13:14, 28 January 2019 (UTC)

Wiki Adminship for Minh Nguyen

I would like to nominate Minh Nguyen to gain this wiki's administration rights. Minh is an experienced wiki contributor, both here and on various Wikipedia languages/sites, and he has extensive technical skills. His latest work is the creation of the dataitemlinks gadget that I just deployed -- it modified our Data items pages to convert wiki documentation text (P31) into proper links. I think he will be a great addition to the admins. --Yurik (talk) 01:36, 28 January 2019 (UTC)

•  Support - for the reasons stated above. Yurik (talk) 01:36, 28 January 2019 (UTC)
•  Support Minh has extensive experience in Wikimedia projects and he would be a good addition to the people who can help out here. —seav (talk) 16:58, 28 January 2019 (UTC)
•  Support Minh has been very supportive of mappers on the OSM-US Slack (including me), is very knowledgable about OSM and Mediawiki, and has been instrumental in getting Wikibase working on the OSM Wiki. —Todrobbins (talk) 22:09, 28 January 2019 (UTC)
•  Support Minh is a SUPER-qualified OSM "technician/engineer/supervisor/administrator" as he is active in Wikipedia, OSM and many excellent endeavors that show both his good spirit as an OSM volunteer and as a highly competent technical guru. He has the chops, he has the right attitude and spirit. Stevea (talk) 03:19, 29 January 2019 (UTC)
•  Support Good to have Minh as wiki admin -- Naveenpf (talk) 05:13, 29 January 2019 (UTC)
•  Support Minh is a great steward of OSM community in San Jose, happy to have him confirmed as admin --Smaffulli (talk) 22:27, 29 January 2019 (UTC)
•  Support - Agree he's a great asset to the wiki for all reasons stated above.—Nicomar (talk) 22:32, 29 January 2019 (UTC)
•  Support Mmd (talk) 07:18, 30 January 2019 (UTC)
•  Support--Władysław Komorek (talk) 09:43, 30 January 2019 (UTC)

---

Seems there is a consensus. Could anyone of the bureaucrats @Firefishy:, @Harry Wood:, @Lyx:, @Pigsonthewing:, @Steve: grant Minh the adminship? Thanks! --Yurik (talk) 01:58, 12 March 2019 (UTC)

Done. Congratulations, Minh! Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:48, 15 March 2019 (UTC)

Wiki Adminship for Tigerfell (renounced)

I would like to nominate Tigerfell to gain this wiki's admin rights. Tigerfell has been instrumental at many changes at this wiki, including many technical changes like the Thanks extension with his pull request. Tigerfell is a good contributor with extensive skillset, and would help this wiki grow. --Yurik (talk) 01:36, 28 January 2019 (UTC)

•  Support - for the reasons stated above. Yurik (talk) 01:36, 28 January 2019 (UTC)
•  Support - Active OSM wiki editor + good handle on mediawiki -- Naveenpf (talk) 05:42, 28 January 2019 (UTC)
• Oppose - Tigerfell is still very new to OSM and describes themselves as a "Wiki" person and obviously has some technical skillset. Unfortunately, Tigerfell lost lots of goodwill in their local community due to the way they handled a recent proposal voting process. Copy-and-pasting forum content and unilateral kicking off a voting process without prior consultation, and unilaterally changing the end date of an ongoing voting process was generally considered as crossing red lines (many have seen this as "tweaking the results in a certain direction", although Tigerfell wanted to give others the opportunity to voice their opinion, in stark contrast to how proposal voting normally works). Link to discussion in the osm forum: https://forum.openstreetmap.org/viewtopic.php?pid=731584#p731584 ... Although I see the general will to improve the wiki and the good intent behind their actions, I wouldn't be very comfortable seeing someone with such basic understanding how OSM processes work in an OSM wiki admin position. Connecting more with the local OSM community would certainly help in this situation. My suggestion would be to try again in 1 year, and keep going improving the Wiki! Mmd (talk) 06:48, 30 January 2019 (UTC)

•  Support - Has been very supportive. --Władysław Komorek (talk) 09:49, 30 January 2019 (UTC)

Thank you for the nomination and the feedback. I have thought about this by myself now and I have drawn the conclusion that I lack some experience to do this now, but I would be happy to take the responsibility at a later time. --Tigerfell  (Let's talk) 19:47, 30 January 2019 (UTC)

Criteria for deleting wiki content

There is an ongoing discussion about when to delete proposal pages in the forum: https://forum.openstreetmap.org/viewtopic.php?id=65257. This is based on recent reverts in this wiki as well as the need to formulate rules to avoid such actions in the future. Please feel free to join. --Tigerfell  (Let's talk) 12:42, 3 February 2019 (UTC)

We crafted a more general deletion policy for all wiki content which is currently located at User:Tigerfell/Crafting. Please feel free to review or comment. We plan to vote on the draft in about a week (depending how the discussion goes on), so this is somewhat of a last call. :-) --Tigerfell  (Let's talk) 13:13, 22 March 2019 (UTC)

Proposal to change Proposal process

I would like to propose a change to how we discuss new tags. I think we can make the process a bit more streamlined, with the fewer "gotchas". In short, I think we should just create new Key:* or Tag:* pages, add some warning at the top (e.g. "this tag has not yet been approved by the community"), and use the corresponding "talk" page for discussion and voting. There are a number of advantages of this method:

• All documentation is always in the same structure, without the need to copy some of the discussed content to the tag pages after the discussion is over.
• New users already tend to create new tag:* or key:* pages when making proposals, and wiki maintainers often have to move those to the Proposals namespace, so the new way will be more intuitive.
• Corresponding data items will become more useful, because they will be associated with the right pages and contain proper description, and thus if someone already uses those tags in OSM, iD and taginfo will show proper description from the start, even before the tag is approved.
  • It will be possible to query for those tags using Sophox queries even when they haven't been approved yet
• Discussion will always be attached to the tag (as part of the talk page)
• For non-English speakers, it will be more straightforward to make a proposals in another language, rather than trying to figure out if it should be Proposal Pt:* vs FR:Proposal/*.
  • Translating proposals would be the same as translating any other tag - e.g. given Pt:Key:Foo, someone could create a corresponding Key:Foo for the English speakers and a more general discussion.
• If the proposal is rejected, there still will be a dedicated page to the rejected tag, with a clear note at the top discouraging its usage.

--Yurik (talk) 18:37, 15 February 2019 (UTC)

I see several issues with that idea:

• Many proposals suggest more than one key or tag, and they only make sense as a whole.
• Proposals do change or deprecate tags, they don't just introduce new ones.
• Sometimes, there are competing ideas for the same tag.

Overall, a proposal isn't a key or tag – it's a suggestion to add, change, or remove one or more keys/tags. If we imagine key/tag pages as source files in a repository, then a proposal would be a pull request (which contain parts of source files, but are not themselves a source file).

I absolutely agree that there should be data items for proposals, by the way. But I feel it would be more appropriate for them to be instances of "proposal" (rather than key or tag) with appropriate properties: Proposer, dates of draft/RFC/vote, vote outcome, affected keys and tags, ... --Tordanik 20:14, 15 February 2019 (UTC)

@Tordanik: thanks! I have been thinking about some of those concerns too. I think the main difference is how we approach OSM tag documentation - proactive vs reactive. In proactive, we plan before tagging. A mapper would create a proposal detailing all the changes, participate in a community discussion, vote, and finally move proposal content to the Key:* and Tag:* pages + translate it. In reactive, some mapper would simply start adding new tag to the objects in OSM, possibly after agreeing about it with their local community. While we may desire the former, the reality is usually the later. We have 70,000+ unique keys, not even counting tag values - compare that with the number of proposals :). So I think wiki should reflect that reality, no matter how much we may wish for it to be different. It is better to have "some" documentation for the tags used in the live OSM data, and steer the discussion/voting process afterwards, and have discussion attached to the wiki page after it completes, rather than to try to have a top-down process that is not followed far too often, thus creating a duality - some keys have wiki pages, some have proposals, some just exist without much documentation.

My idea would allow us to address that - by having a data item for each unique key and tag (when warranted), plus a wiki page if there is more content than basic infobox, plus an easy place to discuss it on the talk pages, even if the key/tag is already in use. Essentially we would have the same process for both proactive and reactive - regardless how the key/tag was first introduced. Moreover, the data item could be created directly by iD or JOSM when user tries to add a new key with a short description - thus we will always know what the user meant when they added it, and experienced mappers will have a chance to steer them towards better practices. To start a discussion about a data item/wiki page, simply add a talk page with some header template, e.g. {{Discussion}}.

Changing existing tags or keys is essentially a discussion about a subject -- that's what talk pages were initially created to handle - you simply create a new section with the proposed change, and have a well defined way to discuss that change. Multiple changes go under different headers. In case it goes too long, you can always use subpages.

Multiple keys can be discussed in two ways: either on a "primary" key talk page, with other key pages linking to it, or on a dedicated proposal page, with every related key/tag page linking to it. This is similar to what we have now, but the important difference is that the key:* page will exist and reflect that it is already being used in OSM data, even if used by 10 objects, and provide documentation for those 10 objects. I don't think there will be too many of those "meta discussions".

I think adding "instance-of = proposal" data item would have very little value -- it will not be discoverable by iD or JOSM (which use Key:foo when looking up documentation). Much easier to add status (P6) = under discussion / approved / rejected / ... to the proper key/tag data item, and have iD/JOSM react properly to that. --Yurik (talk) 21:26, 15 February 2019 (UTC)

There are a lot of tags and keys (probably a vast majority of those 70,000) which do indeed not require any long-winded proposals – adding a new shop=* value or such. And those most of the time do not go through the proposal process at all, which is perfectly fine. The same goes for the kind of minor changes that can be discussed on a talk page or the tagging mailing list.

But when it comes to big steps for our data model, my experience has been that these tend to succeeded only with a lot of documentation, discussion, and planning in advance. I'm thinking of concepts like the :lanes suffix, Simple 3D Buildings or Conditional restrictions. Mappers spontaneously making up a new tag and typing an explanatory sentence into iD/JOSM is just not going to result in a solution for these more complex problems. Not one that can be used robustly by a wide range of data consumers, in any case. This, too, is a reality we need to accept.

So while topics requiring a "meta discussion" may be less common in absolute numbers, they also seem far more important for our project's future. Therefore, I feel it's essential that our proposal process is designed to handle them especially well. They should not just be an afterthought compared to simpler, single-tag proposals. --Tordanik 19:54, 16 February 2019 (UTC)

@Tordanik: 70,000 are just the keys, I did not even look at the number of values we would have for the "enum-like" keys. Also, just in the past 2 months, at least 4 key/tag pages were renamed from "Key:..." to "Proposed features/..." form, e.g. @Woodpeck: has moved motorcycle:scale to proposals because it was not well established, even though there are over 100 usages of that key in OSM data. This means that while in discussion, there is no proper documentation for motorcycle:scale key, and it is less likely that many users will even bother documenting a new key if there is a documentation delay like that.

I agree with you about big strategic discussions. E.g. disputed borders was clearly a proposal that spans far wider audience than a specific tag. I think my proposal should only target simple new keys and tags, and also changes that are scoped to a singel key/tag. --Yurik (talk) 18:27, 18 February 2019 (UTC)

"Corresponding data items will start working right away" - that is not a good reason to change anything in proposal process Mateusz Konieczny (talk) 21:32, 15 February 2019 (UTC)

@Mateusz Konieczny: That was a side benefit, not the primary reason :) Data items get created right away as soon as they are added to the OSM data. When created, they are missing description, making them less useful. Following this process makes them far more useful, while still allowing us to discuss it, vote on it, change status properly, etc. --Yurik (talk) 21:43, 15 February 2019 (UTC) (P.S. I updated it above)

I think that this is a big step forward in allowing many "shy" mappers to create proposal pages. It will also trigger the involvement of people who do not speak English, and it would make the whole proposal process much more streamlined. For example, among the Polish community, we have a few very active people, but they are afraid to write a proposal because their knowledge of English is too weak. Good job! --Władysław Komorek (talk) 07:51, 16 February 2019 (UTC)

Hi, I liked the idea at the first glance, but than I had second thoughts.

I still think it's a good idea, but only when limited to creating new tags. When changing something either we will have the actual change somewhere among existing information and it will be difficult to see what we are exactly talking about, or the changed part will be separate (like at the end of wiki page) and it will be easy to discuss, but what after voting? Again, two possibilities - either it will stay at the end, then we will see the process of changes, but wiki page will be inconsistent; or the author will have to edit the page so that documentation for tag is consistent, but that means that the page needs editing anyway, so we lose the advantage of having wiki page ready even before the proposal.

So, your idea is good as an alternative way of creating a proposal for a new tag, but it can't replace the existing proposal process.

Rmikke (talk) 14:01, 18 February 2019 (UTC)

@Rmikke: thanks, I agree about significant changes. For minor changes limited to a single key or tag, you could use the "discussion/talk" page of that Key:... (just like we are doing now with this discussion) - create a section saying "lets change this key to be X", discuss it, vote for it, and when the voting has been decided, update the primary key page with the new information. This way all single key-related discussions will stay attached to the Key:... page. So yes, someone will have to update the primary page after the discussion. --Yurik (talk) 17:17, 18 February 2019 (UTC)

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)

Visual editor isn't usable because of {{Fa}} template

By putting the {{fa}} template at beginning of Farsi pages, content of the page will be wrapped into it, and so, Visual editor doesn't allow direct editing, but we should edit the content via an interface like text editor.

I found out if I put direct HTML of the template instead of the template itself, visual editor will work.

An example page that uses the {{fa}} to make the page RTL, and the same page that uses the following HTML directly (HTML code from template):

<div lang="fa" dir="rtl" class="mw-content-rtl" style="direction:rtl;text-align:initial;font-family:'Noto Naskh Arabic',Noto,'Segoe UI','Iranian Sans',Tahoma,sans-serif;font-size:initial;line-height:1.6">

My question: is there any solution to avoid using this long piece of HTML code and at the same time visual editor work properly? iriman (talk) 13:15, 22 May 2019 (UTC)

What formatting and templates (if any) do multilingual WMF wikis such as Wikimedia Commons, meta.wikimedia.org and Mediawiki.org use? Does the Visual editor work there? --Andrew (talk) 19:09, 22 May 2019 (UTC)

seems they don't have visual editor as we have here. It's a translate functionality. but on commons there is some templates, for example main page in persian wikimedia commons has a template that uses langcode parameter, however I couldn't find visual editor. iriman (talk) 13:37, 23 May 2019 (UTC)

I tried out a workaround so that for using it without a parameter we should use <div {{fa}}> instead of bare {{fa}}. Apparently it works. Please take a look at my draft. iriman (talk) 14:22, 23 May 2019 (UTC)

I want to modify {{Fa}} as its sandbox version. Then change all instances of {{fa}} to <div {{fa}}> on all pages of this wiki (~300 pages) with a comment for users who are following those pages.

This will not hurt inline ones {{fa|some text}}, as you can see in my draft mentioned on previous message.

I cannot do this task manually, and willing someone do it automatically.

After that we also need to update {{Ltr}} (~50 pages). iriman (talk) 14:51, 24 May 2019 (UTC)

Regarding your question: WM Commons seems to use the page content language property. According to the MediaWiki documentation, changing the page language wraps the content area in <div lang="xyz" dir="ltr/rtl" class="mw-content-ltr/rtl">page content</div>. So, in this case it would be <div lang="fa" dir="rtl" class="mw-content-rtl">.... This solution looks a bit more professional for me, but it would not necessarily include the additional style definitions by {{Fa}}. Is that an issue? (from a technical POV, we would need to request the system administrators to carry out some configuration changes and it may take a few days to review.) --Tigerfell  (Let's talk) 18:08, 24 May 2019 (UTC)

There is no Special:PageLanguage here though. --Andrew (talk) 08:44, 25 May 2019 (UTC)

That is what I meant with "configuration changes". First of all, they would need to enable setting languages for individual pages using $wgPageLanguageUseDB and then they need to assign the pagelang permission to some user group. I'd suggest either user or autoconfirmed (most of us are a member of both groups). The special page will then appear. The procedure for changing the page language would then work similar to changing the page content model using Special:ChangeContentModel. BTW, we could save the rest of the markup of {{Fa}} in MediaWiki:Common.css. --Tigerfell  (Let's talk) 10:57, 25 May 2019 (UTC)

@Tigerfell Definitely your solution is more professional. Font of the page and line height are important but not as important as page direction. With your solution if we'll have visual editor, I think we would be comfortable with it. iriman (talk) 11:24, 25 May 2019 (UTC)

@Iriman: The feature was added in openstreetmap/chef/pull/239 ^GitHub. I already tried it out in my sandbox. Regarding the rest of the formatting, I would suggest you make an edit request at MediaWiki talk:Common.css for all RTL languages' formatting. --Tigerfell  (Let's talk) 20:52, 4 June 2019 (UTC)

Nice! Many thanks for following up on this issue. Ok, I will make a request there, thanks for the link! iriman (talk) 23:39, 4 June 2019 (UTC)

@Yurik: Is it possible to set this for all pages with language prefixes in their names by bot? --Andrew (talk) 06:21, 5 June 2019 (UTC)

Yes, it would be a fairly simple bot that would call action=setpagelanguage, but I am not sure how the bot will know the current language of the page - I couldn't find the api for that. Perhaps the bot will just keep a list of pages it has already modified. --Yurik (talk) 18:46, 5 June 2019 (UTC)

All pages except for those changed recently (after the configuration change) are in English (default language for this wiki). --Tigerfell  (Let's talk) 20:10, 5 June 2019 (UTC)

+1. Also we need to remove {{Fa}}, {{Ar}}, etc. from beginning of those pages. But note that there may be some of these templates currently explicitly transcluded in block mode {{fa}}...</div> or inline mode {{fa|...}}. They should remain as they are now. iriman (talk) 19:01, 5 June 2019 (UTC)

Actually currently we may have {{fa}}...</div> or inline mode {{fa|...}} in other namespaces that are ltr. not an issue here. iriman (talk) 08:16, 6 June 2019 (UTC)

Long term maintenance could be done various ways, for instance putting a warning message and tracking category in the language template if the language set in Mediawiki differs from the one inferred from the page name. Populating the language tags in the first place is the tedious bit. --Andrew (talk) 07:36, 6 June 2019 (UTC)

Why do we need to have the correct language setting for all pages? It would be obviously nice to know and a good info for search engines and the like, but apart from that? --Tigerfell  (Let's talk) 17:23, 6 June 2019 (UTC)

It could be useful for language-specific formatting, for example font face (since it's a common need between all languages). This is a possibility only. Users of a language may need it, or not if default configuratuon satisfies them. For Fa, Ar, He, etc. currently we have font settings on our templates {{fa}}, {{ar}}, {{he}}, etc.iriman (talk) 10:59, 8 June 2019 (UTC)

By use of @Wynndale: idea, I put a general notice on {{Fa}} template for a somehow long term maintenance on Farsi wiki. iriman (talk) 15:21, 13 June 2019 (UTC)

Hi again, could someone please take this issue in hand: Setting the page content language for new wiki pages automatically on page creation iriman (talk) 05:51, 17 June 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)

Replacing the SlippyMap extension

There have been some bugs [8][9] with the unmaintained Slippy Map MediaWiki Extension and there was some discussion how we can replace it (see above). I now opened a request to add MultiMaps extension to this wiki to replace it (openstreetmap/chef/pull/241 ^GitHub). I have outlined how this can be done using a bot at page User:TigerfellBot.

This is a pre-notification (because noting is installed yet). I plan to follow the steps of Automated Edits code of conduct, but in case someone has a question or objection, you can already raise it here. --Tigerfell  (Let's talk) 10:33, 15 June 2019 (UTC)

Can you please post a link to some wiki page with a map shown by this new extension? --Hufkratzer (talk) 11:09, 15 June 2019 (UTC)

• http://fr.nvcwiki.com/index.php/NVCwiki:Mise_%C3%A0_jour_en_cours Outlines the possibilities of this extension, we will be using OpenStreetMap only.
• http://www.jerezsiempre.com/index.php/Capilla_Santa_Gema_Galgani Short page with pictures and a map only.

Basically, you just place a Leaflet box with a map on the page. --Tigerfell  (Let's talk) 17:27, 15 June 2019 (UTC)

The last map on page http://fr.nvcwiki.com/index.php/NVCwiki:Mise_à_jour_en_cours contains a layer switcher. Is this also availabe in the OSM wiki? How? I couldn't find that in  Extension:MultiMaps/Documentation --Hufkratzer (talk) 10:03, 19 June 2019 (UTC)

This map does not use Leaflet, but some Yandex framework. There will be no layer switcher as of now, but you can select from two different tile providers (OSM standard and Thunderforest transport) by using the service parameter. This is similar to Slippy Map MediaWiki Extension. --Tigerfell  (Let's talk) 19:02, 21 June 2019 (UTC)

---

Update: The extension is available for about two months now, but there is a problem with the transportation layer. We are running version 0.7.2 which can not display them, because the never version 0.7.3 which can was not tested on MediaWiki 1.31 (current (LTS) version of this wiki). Since the whole backporting process has stalled about three weeks ago, I guess we will be waiting for version 1.34 of MediaWiki. This version will be probably compatible with 0.7.3 of MultiMaps. --Tigerfell  (Let's talk) 11:21, 17 August 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)

Removing "WikiProject" prefix

Hi, I am Daniel, from Spain. I am renaming the wiki pages related to country mapping project to remove the "Wikiproject" prefix following the pages name conventions.

I have already renamed the United States, Canada, Spain, and all Spanish-speaking countries mapping project pages. I am in contact with the communities in Australia and New Zealand to find out if you would like to rename their country pages as well.

If anyone wants to collaborate, you're very welcome! We need volunteers. (I recommend contacting the local communities first to avoid unnecessary discussions.)

Thank you! --Dcapillae (talk) 21:34, 25 July 2019 (UTC)

I am currently in a loose contact with the mappers from Bangladesh. As it turns out now, they are confused by the prefix and want to restructure the country-specific pages. (Not sure if they just consider doing something of if they have a clear mission.) --Tigerfell  (Let's talk) 09:47, 26 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)

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)

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 [10] 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)