Talk:Wiki/Archive 5

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 [1].

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 [2].

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