Talk:Wiki/Archive 4

From OpenStreetMap Wiki
Jump to navigation Jump to search

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

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

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

Bug: JavaScript error

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

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

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

The slippymap extension is full of bugs, including with very bad HTML/CSS layout. In addition it can only be used only ONCE per page. Trying to display two maps on the page will incorrectly place the children elements or will cause the interaction with one map to affect another map due to collision (no unicity of the generated "id" attributes per slippymap instance).
This local gadget on this wiki is in fact unmaintained since long and nobody seems to be working on it (and it is not part of the standard MediaWiki distribuion, not used by Wikimedia on its sites that uses other extensions and is developing new ones for integrating maps in Wikipedia: for now there's a couple of extensions used to render maps in a popup that you open by clicking on a "map" icon at top of page at end of the title bar.).
Probably it will be replaced later using a new installed gadget or extension. But for now, if you need several maps, use separate wiki pages.
Additionally the slippymap also uses deprecated features of MediaWiki and unsupported internal features that no longer exist. And yes the use of the OpenLayers framework is also non-conforming (as it also uses internal variables in a non-clean way not matching the documentation). slippymaps on this wiki have very limited usage, just to show a basic locator map for the country, region or city which is the main topic of the page. In most cases one one map may be useful; for the rest, create directly a link to the OSM site to render maps in a separate page: you can use templates like {{Node}}, {{Way}}, {{Relation}} to create such links to the OSM map or to a few other tools with specific renderings. — Verdy_p (talk) 15:57, 12 June 2016 (UTC)

ResourceLoader warnings

I also see in the console the warnings 

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

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

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

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

Discussion restored from the archive, because the bug is still there in the old SlippyMap extension created for this wiki, which does not comply to basic requirements and isolation. We still need to fix this extension. For example it's still impossible to render multiple slippymaps on the same page. The only alternative is to use static maps.
The CSS and Javascript code for the SlippyMap extension has not been fixed since years and contains numerous issues reported since long. But not maintained. It has even blocked at some time the migration to newer version of MediaWiki due to compatibility issue. The slippymap extension used in Wikipedia (different versions depending on languages) is much better, faster, and maintained. MEdiawiki will also soon standardize a new version that will work across wikis with less security issues and more accessibility. However it depends on Wikibase and this wiki still does not have this extension and cannot work with remote databases (such as Wikidata).
So it would be good to revive the specific opensource code for the few extensions specific extensions used on this wiki, and finally fix all the severe issues reported. But this requires personal involvments of admins of this wiki, which are in fact not maintaining this wiki at all, and just too busy working on the OSM database instead. There's unfortunately NO active admins on this wiki to fix what they are the only allowed people to fix. And other people just have to find some workarounds, even if they are sometimes very slow or require lot of manual edits for the maintenance. — Verdy_p (talk) 15:35, 24 May 2018 (UTC)

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

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

Links: Case Sensitive and Namespace

Hi,

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

MediaWiki:Lang/xx pages

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

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

per-page usage stats

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

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

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

See above, user:Verdy p worked on the corresponding templates but he currently hadn't fixed that bug. I will ask him again :) --!i! This user is member of the wiki team of OSM 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! This user is member of the wiki team of OSM 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):

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)

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:

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

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

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

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

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

Semantic MediaWiki

Hi all,

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

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

Some points I see speaking in favor of SMW are:

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

Please tell me what you think!

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

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

Proposal for creating group categories

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

These are the groups I am talking about:

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)

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Talk:Wiki/Archive_4&oldid=2600978"