Talk:Wiki: Difference between revisions

Revision as of 16:12, 9 December 2018

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

Limiting TOCs

Hi, I putted Template:TOC_limit from mediawiki here to control the depth of TOCs but it doesn't work. Can anybody please take a look if I did something wrong? --!i! 08:27, 23 March 2011 (UTC)

The template does not do anything interesting, it only marks your wish. The real work is done by the relevant part of MediaWiki:Common.css (search for toclimit there), which would need to be copied here as well. --Mormegil 16:55, 4 May 2011 (BST)

Ah ok, well I dont think it's not that important. You can tweak the formating using bold lines. --!i!

07:50, 7 May 2011 (BST)

I am in strong need of this ToC-depth-limiting functionality - I need to add some content to a page which would make the ToC very long, on account of many level 4 headings in the content. Can someone please add it as soon as convenient? --Contrapunctus (talk) 18:39, 4 May 2018 (UTC)

fixed --Tigerfell

(Let's talk) 14:25, 29 September 2018 (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 definitions will be limited per their scope:

formal:Key: will cover single key
formal:Tag: will cover single value
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:

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)

Map_Features not available - HTTP Error 500

Hi,
since a couple of days I am frequently facing issues to access the articel Map_Features. The issue occurs for the artikel in EN as well as for DE. Usually the error ERR_EMPTY_RESPONSE returns, today I got once HTTP error 500. I tried different devices PC and Android as well as different access points. In very rare cases the page is loaded sucessfully. Am I doing somenthing wrong or are others facing similar issues? --Meinf (talk) 15:56, 6 August 2018 (UTC)

Well, the page seems fairly long and full of links. Could that be the cause for the problems? I could view both versions on my computer today but it took some time to load. Maybe the server was under heavy load when you requested the pages? U30303020 (talk) 22:15, 17 August 2018 (UTC)

269 categories for Belgium

https://wiki.openstreetmap.org/w/index.php?title=Special:WhatLinksHere/Template:Regions_of_Belgium&namespace=14&limit=500

This number doesn’t include categories such as category:Brussels that don’t use the template.

--Andrew (talk) 18:48, 4 September 2018 (UTC)

Error? Seems ok to me. Tigerfell

(Let's talk) 20:38, 4 September 2018 (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)

Reworking Delete

I expanded this article. It describes the general setup of the deletion process. My main source was my experience during clean up actions, so you may want to recheck that and assure that I got everything right. Thx. U30303020 (talk) 21:36, 17 September 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:

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.
The pages were automatically sorted in categories by the name without language prefix (with the ability to override if needed). This no longer works.
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.
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.
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:

Dependencies towards a singular website should be avoided (see issues with Simple image extension).
No direct dependency towards OpenStreetMap tile servers (puts loads directly on the servers).
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)

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. 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. --Tigerfell (Let's talk) 22:11, 13 October 2018 (UTC)

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.

examining if Kartographer extension works with maps from our tile servers
requesting if Maps extension can be altered to drop the necessity of using composer.
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)

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)

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)

@@ Line 495: / Line 495: @@
 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. --[[User:Tigerfell|Tigerfell]]&nbsp;[[File:OSM logo wiki small2.png|text-bottom|16px|This user is member of the wiki team of OSM|link=wiki/team]] ([[User talk:Tigerfell|Let's talk]]) 15:54, 9 December 2018 (UTC)
+: [[User:Tigerfell|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. --[[User:Yurik|Yurik]] ([[User talk:Yurik|talk]]) 16:12, 9 December 2018 (UTC)
 == Optimizing wiki templates ==

Talk:Wiki: Difference between revisions

Revision as of 16:12, 9 December 2018

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

Bug: JavaScript error

ResourceLoader warnings

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

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

Links: Case Sensitive and Namespace

Limiting TOCs

MediaWiki:Lang/xx pages

per-page usage stats

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

ParserFunctions version

Mediawiki extension for inclusion of sections

Translations

Invert translated local pages

Searching templates

wiki dump

Navigation by use cases

wiki search

ORCID identifier template

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

Semantic MediaWiki

Proposal for creating group categories

Option 1 - Capitalize first letter of Group

Option 2 - Make the first letter of group lowercase

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

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

Option 5 - automatic, but different standards based on language

Talks

Voting

Relation multipolygon and onRelation=no?

Wikibase

Use Listeria

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

Direction of preview for section editing in RTL mode

Map_Features not available - HTTP Error 500

269 categories for Belgium

Rewriting Template:Relation

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

Reworking Delete

Roll back {{Languages}} template?

New Wikibase-based KeyDescription and ValueDescription templates

Optimizing wiki templates

Map extensions

Lua errors with empty BrowseRelation value

This Wiki need a better refresh new image configuration

Installation instructions for Maps

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

Navigation menu

Search