User talk:Verdy_p

From OpenStreetMap Wiki
Jump to: navigation, search
Archives ± : 2012 ; 2015 ; 2016 Jan-Jun, Jul-Dec ; 2017 Jan-May, Jun, Jul-Dec ; 2018


Hi, two questions regarding your recent edits on Key:turn:

  • You say that the text you added to the :lanes-specific section of "Current usage" is not redundant, but I don't see any information there that isn't already present in the "Turning indications per lane" section. Can you point out what information your paragraph adds to the page?
  • When reading the text you added to the "Values" section, I don't see how there's a special rule for value formatting at play. The value of foo:lanes is a list of values for foo, separated by |. The turn key is no exception here. So why is the wordy explanation and example needed?

--Tordanik 10:59, 6 January 2018 (UTC)

Lanes have specific ordering restrictions and syntax where values are actually not first separated (in random order) by semicolons like other tags, the pipes require a specific order even if subvalues delimited by pipes may still use the semicolon for their own unordered list of values.
various editors or users are confused by this specific syntax for ordered lists whose items contain unordered sublists, and the fact that semicolons can be freely reordered or "deduplicated".
Consider this example "none|left;continue;right|left;continue;right|left",
where an editor (or QA tool) may think that the "continue" is duplicate, just like also the "right|left" and can be eliminated automatically,
producing "none|left;continue;right|left" (this is the same number of lanes, 3 here, but the directions are now completely different and only the central lane has multiple turn directions)
The presence of pipes forbids the elimination of these apparent false duplicates.
However in "none|left;right;left" there's effectively a duplicate for "left" and is equivalent to "none|left;right" or "none|right;left" but cannot be reordered (after deduplicating the unorderd sublists) to "left;none|left"...
Lanes definitely do not follow the same standard as normal values for other tags (this is also the case for "opening_hours") and we must say that to instruct users (or developers of editors) so they use specific syntaxic parsers for these tags.
Verdy_p (talk) 13:28, 6 January 2018 (UTC)

Template:State Entry NA

According to the CSS specification, vertical-align doesn't inherit. What are you referring you, then? What specific usecase is there that specifically requires vertical-align:baseline to be defined?

I'm asking the same for text-align:center. Both the parent and the child are fixed at 32x20px size, so there's nothing to align. -- Prince Kassad (talk) 09:16, 9 January 2018 (UTC)

The file may not load when there are some custom values, and in that case the image size will not be used at all but an alternate text appears; or the icon exists but may already be smaller than 32x20px and it won't be enlarged (note that the icon is NOT necessarily an svg). There are other compatibily tricks that cause this template to have strange behavior in some pages whose lists of icons will be broken without this (also when we use an image on this wiki, it as an incorrect vertical alignment, meaning that it does not have the expected height but is in fact in a higher box; without the height, icons that wrap in a column may not wrap to the left margin but to the bottom right of a previous icon leaving some large gap, then some icons later will be wrapping correctly or not; controling the effective display box size of icons is difficult when we actually don't know the effective size of the imager that will effectively be used, and the actual font size of substitutes which may appear). And not that this is not the only template to be used, it appears in a series. — Verdy_p (talk) 10:05, 9 January 2018 (UTC)
Note that you didn't actually answer my question. Under which circumstances can the vertical-align for this element be anything other than "baseline"? Like I said, this attribute doesn't inherit. If you use Firefox you can use the built-in Firebug debugger (presumably this should work with Chrome and its debugger too, but I don't use Chrome...) and go to a page like e. g. Main-Kinzig-Kreis and uncheck the "vertical-align:baseline" from the images. You should notice that nothing happens at all, and the vertical-align for these objects is still set to "baseline" because that is the default.
Also, the problem you mentioned is not a problem with raster images but a problem with image ratio in general, because MediaWiki will never change the image ratio on any image, be it SVG or a raster image. Preferably, we should just not allow images that are not already the correct size unless there's a really important template that calls this template with a nonstandard image size (but I couldn't find such a template anywhere on the wiki...) If we do want to allow this, the CSS should be moved to a place like MediaWiki:Common.css instead of being embedded inline potentially a thousand times (some pages have a lot of calls to this particular template, and every byte adds up). -- Prince Kassad (talk) 11:06, 9 January 2018 (UTC)
that template is already sufficiently packed even for pages that include them many times, those pages that explode are generally much too large and cover too large areas which should have their own subproject pages. and common.css is certianly not a place to put that where it would still be used on a minority of pages and there are other ways in various project pages to show the progresses, for tables that are likely to have a limited lifetime focusing on something else (you have diufferent goals for transports, buildings, commerces and services managed by differnt people at very different times and in differently focxused areas with their own data sources. — Verdy_p (talk) 12:28, 9 January 2018 (UTC)

Please, start using edit descriptions or stop editing

You again made entire series of edits ( is one of them) without edit description. Please, stop doing this Mateusz Konieczny (talk) 16:26, 10 January 2018 (UTC)

Wrong, I commented twice the two goals of these edits the other ones were minor readjustments/reordering... — Verdy_p (talk) 16:28, 10 January 2018 (UTC) is an entire series of edits without description. Please stop editing like that Mateusz Konieczny (talk) 16:30, 10 January 2018 (UTC)
You just want to read what you want from the history, stop this harassment: if you received a notiofication, the first one was commented and you got the others in the same series from the start. — Verdy_p (talk) 16:39, 10 January 2018 (UTC)


Hello, can u move Tr:Main Page to TR:Anasayfa? I can't move, Idk why. --Hedda Gabler (talk) 14:10, 21 January 2018 (UTC)

No don't use the "TR:" prefix entirely in capital. Turkish is recognized on the wiki using the "Tr:" prefix (this is explained on the link at top of pages about how to translate). — Verdy_p (talk) 14:21, 21 January 2018 (UTC)
I moved it to Tr:Anasayfa (after fixing a few things in the Turkish page and adding some missing translations). — Verdy_p (talk) 14:37, 21 January 2018 (UTC)



please, see the history, it worked before your changes: --Reneman (talk) 14:21, 25 January 2018 (UTC)

The problem is that Quote has always contained multiple paragraphs, and alwaus contained "div" elements sour signature and source.
It has also always contained lists in the inner text.
One solution is to use only parameter 1= when it is a single line (in which case it will be surrounded internally by a "div", and parameter text= if it contains multiple paragraphs (in which cases it will be indented another way using indent= and the text will not be inside a "div" but on a separate line).
In summary in could not be indent safely with a single line. — Verdy_p (talk) 14:23, 25 January 2018 (UTC)
It's possible you're right. But you can't change templates and then lose functions that were there before. Similarly, it is not desirable for you to change other users' discussion pages just to "correct" your template change. Find a solution to make the template work in your original version, or leave it as it was. This also applies to other templates (e. g. MyLang). Thanks. Read in German. --Reneman (talk) 14:34, 25 January 2018 (UTC)
This was the case when I did it 2 years ago (sic!) and this was already a problem at that time that needed a fix.
But the talk pages in questions where it was used have NEVER worked with it!
Since the begining the template was intended to quote more than one line and it was used this way before your talk page. — Verdy_p (talk) 14:36, 25 January 2018 (UTC)
Your changes to the template were made on Jul 13,2016. My discussion page is from 26 Sep. 2015, the discussion at Segatus is from 3 July 2013, please stop telling untruths! If you continue like this, I will not get past a side protection for the affected templates and discussion pages. This is my last warning! Read in German. --Reneman (talk) 15:11, 25 January 2018 (UTC)
The template was used long before (in 2011 !) your talk page (2015) to quote paragraphs including multiple lines since the beginning... In 2016, I had to fix it to support embedded lists (starting by asterisks), because they were already not rendering correctly when glued directly after the starting div tag in the middle of a line: the lists were not shown properly, and it was within articles, not just for unmaintained user talk pages.
So stop telling me that I tell untruths. You're definitely wrong here, you're telling untruths yourself. I've considered the case of your old talk pages by a compromise (distinguishing parameter "1=" and "text=", but also documenting/explaining the caveat, which was not the case before). In fact it has never worked correctly in 2015 even in your talk page that you want to demonstrate as a proof (incorrect indentation of the text after it) and my change in 2016 did not solve that.
Also even your talk pages were not correctly indented (you added text after the quote on the same line, that text was already rendered unindented on a separate paragraph. , the talk pages in questions were always (and are still incorrect) if you don't fix the indentation and line separation).
So you've not really looked what was occuring: all your recent reverts do not fix anything, they just restore a solved problem in more important pages than talk pages.
The main difference between my version and the previous one is that the text in parameter was embedded within a "div" element without any newline separation: in 2016 I dropped that div to allow this text to be in a separate line (the div was then unnecessary as everything was in a "'blockquote" and also followed by other "divs", and that's why any text written on the same line after the quote was not indented). This behavior however was never documented and tested properly, so I have documented this caveat (you removed a statement in the new caveat section, but it is real (and your talk page is also a proof where it has never worked as intended). — Verdy_p (talk) 16:03, 25 January 2018 (UTC)
I see on my DISK at 4 examples that it worked correctly. This template was adopted by Wikipedia. At Wikipedia, they also saw the problem you recognized. The problem was not solved by changing the template. The solution was a new template: w:Template:Block indent. In my opinion, this would be a better solution to use a separate template for the extended usage. Read in German. --Reneman (talk) 16:24, 25 January 2018 (UTC)
But the template was already used before your talk page to do real multine block quotes. So the solution I've found with a compromiez was to detect if parameter 1 is used (one line only, e.g. in indented talk pages) or parameter "text" (multiple lines, needing an alternate way to indent it, with the new parameter indent taking value 0 by default). There was still a bug with an extra newline before the end of the "blockquote element. In both cases anyway it will generate a block element, so this is already a "blockquote", only the syntax allowed for the text in parameter 1 is more limited than in parameter "text" (which was already used for that purpose since 2011, long before your talk page in 2015 where you were using an undocumented "hack").
Sorry but without documentation and proper tests, my edit in 2015 was accurate according to its real use in articles as real multiline blockquotes. But now it's documented and tested (this was never done before you started reverting it, breaking other non-talk pages that you really did not check).
In summary we don't need another template (and also don't need to change the existing correct usages that existed before yours. We can cope with both cases. And yes this required my fix in 2015 for the initial intent where it was broken sometimes (I did not care about talk pages whose usage was not tracked, given the many problems that this wiki has had to track "what links here", if a behavior is not documented and not tested, nobody knows that someone like you has used a "hack" of blockquotes, including in the middle of paragraphs where it contradicts what is commonly a "blockquote" in HTML!). — Verdy_p (talk) 17:42, 25 January 2018 (UTC)
Good evening, I've already told you that if you change a template, you'll be able to maintain the way it works. Please compare line 89 yourself: Appearance 2015 (using User: Reneman/Spielwiese) and the current view. It worked for creation in 2015. I beg you, please: The proposal is to work again as it did in 2015. Read in German. Merci --Reneman (talk) 18:50, 25 January 2018 (UTC)
So your talk page was using inline formatting with the "text=" parameter (where it was already unnecessary to name it): I've proposed above to distinguish the inline formatting (which works now) using parameter 1, and keep explicit "text=" parameter only for multiline text. The template is not used so much that it needs to make them equivalent when in fact inline text never needs a named parameter (this matches the use of most pages). I've documented it clearly, we cannot fix both your usage on recent talk pages and usages in other more important articles where it was broken. The template now distinguish it clearly. It's not so many pages to fix.
You propose another template but this would still require changing one of the two use cases. — Verdy_p (talk) 19:02, 25 January 2018 (UTC)
Yes check.svg Sorry for the late response, I think the subject is done. Thank you for your commitment. Greetings --Reneman (talk) 18:32, 31 January 2018 (UTC)

please use edit comments

Hi Verdy,,_left_%26_right&action=history --21:57, 8 February 2018 (UTC)

Yes, please use comments. Especially editors making many comments should take time to add useful edit summary. Mateusz Konieczny (talk) 22:19, 8 February 2018 (UTC)
This was presentational, mostly, and your revert was reverted by someone else; I did not do anything wrong. My intent was to make the sentence really clear by distinguishing plain language and actual code, and fixing missing underscores that should be visible in key tag prefixes or values (additionally they are not translatable, and this was marked explicitly). As well I removed underscores that should not be there in plain text (because you blindly copy parts of URLs without taking care of their meaning). — Verdy_p (talk) 05:06, 9 February 2018 (UTC)
Thank you. "[M]ake the sentence really clear by distinguishing plain language and actual code, and fixing missing underscores" would make up a nice edit comment. Then other people seeing your edit would not need to think about what you intended to change. --Aseerel4c26 (talk) 08:53, 9 February 2018 (UTC)

Grazie per la modifica alla mia pagina

Grazie per la modifica alla mia pagina personale, non avevo visto questo nella pagina documentazione del template. User:Simone_girardelli 11:52, 10 February 2018 (UTC)

template hell

I reverted and as user added it in an incorrect place. Can you help him/her to add it to correct place? I have no idea how to navigate template hell of translations and you seem proficient at that Mateusz Konieczny (talk) 08:43, 13 February 2018 (UTC)

Reverting these additions is not the best option: it's safer to copy the content to the appropriate transalted page, and then try traanslating it to English in the English page (it should not be difficult do do from Spanish to English, even if you use an automatic translator to help you, and then fix the result to get correct English. — Verdy_p (talk) 09:04, 13 February 2018 (UTC)
In this case, there's absolutely no "template hell", both the English and Spanish page use plain wikitables and no template for autotranslating and formatting that section. — Verdy_p (talk) 09:06, 13 February 2018 (UTC)
Note: the English page is alreasy partially translated to English, with some sections showing other languages (there's nopt necessarily a matching page in that language). Reverting such additions does not help anyone, we can cooperate to move what's needed, and after all the Spanish-speaking contributors does not necessarily knows English and it's fine to paste a copy here of what was added to the Spanish page to maintain the synchronization: it's up to English translators to provide the English translation, just like it's up to speakers of other languages to translate the English text that appears by default in their translated page. That's the natural way to progress in cooperation. — Verdy_p (talk) 11:36, 13 February 2018 (UTC)

MapLesotho Pages

Veryd, quit reverting my edits. I have been a project lead on Maplesotho for 4 years. I am consolidating the content to a single source. Quit your faffing about --DaCor (talk) 16:09, 16 February 2018 (UTC)

Oh and before you write a long spiel, don't bother. I have nothing against you, or your overall wiki edits. You do a lot of good work in the wiki, but leave the Lesotho related content alone. I have been writing guides, reformatting pages and consolidating the content over the last 2 weeks. I don't need to be wasting my time re-doing the same work because you didn't see fit to ask what I was doing and instead starting an edit war. Just stop --DaCor (talk) 16:12, 16 February 2018 (UTC)

Deleting interesting contents even is important for historic interest, you don't need to blank it and create a non-sense redirect (on a page that will simply become unreachabvlen so it's impossible to get its history, it is just enough to name it properly.
Just with a new name for the article you can clearly state that this page is of historical interest (as it still keeps interesting info of what you've done). In aother words I've not destroyed anything in what you did ! and you can contionue on the next phase. — Verdy_p (talk) 18:08, 16 February 2018 (UTC)
review the main lesotho page. its already captured there. like i said, i am working on this for 2 weeks, tidying it all up. im not deleting information that is not captured elsewhere. there will be further work done to the lesotho pages over the following weeks. i suggest you wait until its all completed before making futher edits to those pages. like i said before, ive nothing against your work in the wiki, it works more efficiently because of what you do, just trust that i have similar objectives --DaCor (talk) 18:23, 16 February 2018 (UTC)
Sweet mother mary, can you stop! Seriously! I'm trying to talk to you about it here and you keep f@#king with the pages. Leave them alone. Let me finish my damn work. I've wasted hours this evening pissing about with you when I could have been editing other content. Just stop. I'm beginning to think this is bordering on malicious actions as I've asked you to stop 3 times now and you keep interfering. Stop. Let me finish my work. Quit interfering with a work in progress. I shouldnt have to keep coming back to this page to ask you them same thing. Let me finish, then you do whatever the F@#@ you want --DaCor (talk) 18:37, 16 February 2018 (UTC)


Subpages in this article has to be categorised --Naveenpf (talk) 06:18, 27 February 2018 (UTC)

There's lot of incoherences in names, this is not so easy to do in one step. I try to do my best to improve the navigation in these Indian projects, so that they can be completed, improved, refreshed, or abandonned. — Verdy_p (talk) 06:20, 27 February 2018 (UTC)
@Naveenpf, @Heinz Z: I hope you appreciate the categorization and navbar for States I added to India project pages. Highways are now categorized and navigatable as you wanted.
Some other categories avec been cross-referenced where needed, so you will find relevant links more easily.
Note: the navbar for States of India is autotranslated, which means it can be used on translated pages (not just English). I've initialized some languages and filled the first entries with more translations, but this can be continued to support more languages (e.g. Hindi, Urdu or Tamil are the most frequently used with active translators).
I will finish initializing the articles for each state with the {{Place}} template (articles for some states or territories are still missing, so you may still see some red links, but their categories are all there, you have examples however in existing pages for states). — Verdy_p (talk) 02:01, 28 February 2018 (UTC)

Comenius Pages

Although you speak German very well according to your own statement, I try it with my bad English. WHEN will you finally stop fiddling around in other people's sites (where you don't have the slightest idea about the content)? Are you the wiki police? You destroyed so much that I might have lost a project this morning. Where did the Navbar go? Why you can decide what is sufficient and what is not. Please choose 10 bad words and say them to you with a nice greeting from me. Your arrogance and self-importance are unbearable.

Oh, and before you write a miserably long sermon, don't bother. Why do you do so many things in the wiki that you don't have the slightest idea why someone else did something exactly as he did it? A little self-reflection on your part would be helpful. fredao 10:57, 28 February 2018 (UTC)

It's not me at all !!! The history shows there's been lot of edits made by others, and all I did the last time was to put the page in its own category. Other edits are not mine !
Note that hte navbar for languages has never been in that page, and it was added last year by a ginle edit made last year by someone else.
I've not made any change since months (the last one was to add its category, so I've not broken anything.
Really stop complaining without any proof or good reason, read the history correctly. Your attitude is just needlessly doing a personal attack without reason and on false bases. You have just most probably forgotten what YOU did yourself in 2015, and then you forgot these pages (which initially were not correctly linked between each other and not properly categorized, my only edits already linked them together, I've not removed any links!). You are the only editor of this page before for most edits made in 2015, and I've not deleted anything ! — Verdy_p (talk) 11:13, 28 February 2018 (UTC)
@fredao Instead of complaining for things that I had NOT done myself, I was looking at what was wrong, and this was made by someone else breaking some links with incorrect redirects (mixing Galician and Spanish). I have restored the situation and made the navbar usable across all existing versions. In summary I did not make anything wrong more than one year ago. If you're looking for the Galician page it was not deleted by me or anyone (only one page was incorrectly renamed by someone else), I did not delete any navbar.
But I just kindly added (for you!) what was missing, and fixed a lot of incorrect links in what you wrote yourself in these pages, including bad basic Wiki syntax, incorrect CSS, incorrect HTML, various typos, correct categorization by language... all is navigatable again.
But you won't excuse yourself and won't say any "thank you" for these fixes. If you continue this kind of offensive message I will signal your attitude, which was both arrogant and insultant, irrespectuous, and with false claims everywhere! I better know what I had done (and I have very good ideas about what was on the page), you just don't know at all what you did 2 years ago (not the "slighest idea" using your own terms)... "A big self-reflection on your part would be helpful" before posting such abusive and false complain. — Verdy_p (talk) 17:33, 28 February 2018 (UTC)
@Hi verdy_p THANK YOU very, very much for doing, what you did on the page. And especailly for restoring the Navbar! ... Once again THANK YOU for your help. Je vais maintenant contacter à nouveau l'Agence nationale de Bonn. J'espère qu'on pourra réparer la mauvaise impression. Enfin, il s'agit d'un futur projet scolaire avec des partenaires du Royaume-Uni, de l'IE, du PT, de l'ES et de l'DE dans le cadre duquel nous voulons offrir une formation humanitaire OSM aux étudiants de ces pays. Encore une fois, je vous remercie et je m'excuse pour le dérangement, mais j'ai vu tout le travail que j'ai fait pour ce nouveau projet "s'envoler". Si le nouveau projet est approuvé, je vais connecter ceux qui écriront le wiki pour le projet directement avec vous afin que tout soit en ordre dès le début. Meri - et pardon, mais j'étais désespérée et en colère en même temps ! ;-) fredao 11:12, 1 March 2018 (UTC)
@fredao Je ne vois pas du tout quelle page s'est "envolée". Si je recherche dans tes contributions passées, ces pages sont toutes là. Je pense que tu as du oublier d'enregistrer tes modifications, ou bien tu n'as fait qu'une "prévisualisation" et tu ne l'as pas confirmée, tu es ensuite allé ailleurs, tu as fermé l'onglet de ton navigateur et cela n'a logiquement pas été conservé.
Note : pas besoin de me réexpliquer ce projet qui est déjà bien expliqué dans les pages elles-mêmes. Ce n'est pas un "futur" projet mais un projet depuis plusieurs années. Tes modifs que je vois sur ces pages sont datées de... 2015 ! Tu as certainement oublié depuis ce que tu avais fait. Regarde ton propre historique !
Note 2: je n'ai pas "restauré" la navbar, soit elle n'a jamais été là, ou bien elle était masquée par défaut car il y avait plusieurs navbars dans la page (c'est un effet par défaut du modèle utilisé qui oblige à la dérouler, un effet réglable si tu veux qu'elle soit déroulée en permanence quel que soit le nombre de navbars dans la page). — Verdy_p (talk) 13:21, 1 March 2018 (UTC)


As always...

Please make an additional edit there with a comment. Thank you.--aseerel4c26 (talk) 21:39, 1 March 2018 (UTC)

This was true before I edited it (with a comment !) to split it in subpages as there were too many relations listed on the Monster Relations page (for "/sub 1000").
Look at the history: then the update was made in several successive steps to avoid breaking anything in termediate stages. Finally I linked the additional subpages that were splitted.
As I looked at the expansion I made the code wmaller (still easily editable) by packing tables to lmit the next occurance of page expansion limits (I made it first in the "/sub" 1000, then appleid it consistantly on the parent page for the parent page listing 1000+). There's not been any change of data in the tables. — Verdy_p (talk) 21:41, 1 March 2018 (UTC)
I see your comment on , yes. But there is still no comment in for your last four edits. Please just tell people looking at the page history or their watchlists what you did there. The diff is very unreadable, so your comment is essential. Thank you. --aseerel4c26 (talk) 07:14, 2 March 2018 (UTC)
Unreadable ? This is processed by very basic regular expression transform : no addition of data, just making it work and more compact and easier to edit. Well it was done AFTER the "/sub 1000" relation was splitted and foratted the same way (once I had made it work in a subset created in a new subpage, I could then remove these splitted part from the initial page. There were several edits necessary, the first one was commented, then it was following under the same applicable comment. — Verdy_p (talk) 07:18, 2 March 2018 (UTC)
Yes, the mediawiki diff is quite unreadable. Please just comment you did to the page. Why is this that hard? --aseerel4c26 (talk) 19:59, 2 March 2018 (UTC)
No it's not hard but for this page, I forgot it because I thought I was editing a new page, it was mde in jsut a few seconds using regexps, after creating the new splitted pages with comments.
I can ensure that I did not delete anything, only made the page adopt the same format used for the new "/sub *" subpages that now work (the older "/sub 1000" was not working at all due to expansion size; for I disabled a part of the templates, then I splitted it on subpages were I could restore the tools; then I kept the "/1000" subpage in the same working format, and finally I updated the main page for "1000-5000" to the same working table format, only to reference the additional subpages created by the split).
If you don't trust me, open two windows side by side to compare the rendered result from the history: all is there, with the addition of the new link to subpages.
Note: this list is old and would need update (but not the same format that was tried and that did not work: I updated it to show that it is possible to refresh it correctly). — Verdy_p (talk) 20:05, 2 March 2018 (UTC)
Verdy, please read W:en:Help:Edit summary. --aseerel4c26 (talk) 20:08, 2 March 2018 (UTC)
Stop, asking this, I usually don't comment pages I create, there's an automatic comment for that. Also if several successive edits are needed (because it cannot be done immediately or because I fix a typo immediately), no additional comment is needed after ther first one, this is the same edit in a group with the same applicable comment.
You could say that to every one one this wiki. I more frequently use comments that almost all users. and in this case this was a minor edit to add a link, and as it was mde in just a few seconds, I forgot it on that page while I linked the 3 subpages and only formated the table to reduce the server workload. As well this page was not maintained since VERY LONG, so you should not care about it, given you did not care before that it was NOT working at all, you should thank me for making it workable again ! All I did was basic maintenance becauise this page was in a list of pages in severe errors reported by Mediawiki itself (and caused significant resource usage on the server each time it was accessed, including by remote indexing bots). — Verdy_p (talk) 20:15, 2 March 2018 (UTC)
"no additional comment is needed after ther first one" - yes, fine. But I cannot find the first comment, please help me: --aseerel4c26 (talk) 20:31, 2 March 2018 (UTC)
"Help me?" I've already comment that to you, and you are alone to ask, and I already replied above. Reverting is clearly not a solution, because you actually didn't care at all about that page for years, and nobody else ! Apparently you just want to make the wiki break again each time this page is hit ! — Verdy_p (talk) 20:34, 2 March 2018 (UTC)
Thank you! You see that I care about that page because I edited it - and it worked.
I care about the wiki. The wiki is nothing without a wiki community. A wiki community does not work if you refuse to comment your edits.
Something non-meta: I am quite curious what in the old table formatting creates a higher workload that the new table formatting. --aseerel4c26 (talk) 20:40, 2 March 2018 (UTC)
There are visible statistics on page: reports generated by bots should look at them, and it's not always necessary to split each cell on separate line when it is better readable on the same line to have a global view. Usually I split cell rows on separate line when the cell contents are very variable, or if there's some consistant markup to apply, but here the fields are very short and almost all the same length.
The work load however was extrmeely bad in the "/sub 1000" subpage which crashed after trying to render it (using about 2 minutes of server CPU and lot of memory and I/O swaps to disk, so this explains the very long delay... until the page finally was broken and could not be rendered). And this crash occured at each visit (a failing page is not cached: each time it is visited, the server attempts again to render it, and such page as good targets for DOS attacks against the server, just by visiting them repeatedly without even editing them, so there's a real need to do the maintenance to avoid this severe issue!).
Believe me, I use the statistics of the server to tune all templates, and I have improved the most widely used one often from 30-50ms on average to just 1-3 ms by taking much care about what is expanded and what is not and how to reduce the non-trailing recursions and repeated parsing. MediaWiki has an interesting feature for rendering templates: it uses a cache, and there's a way to use it as much as possible to speedup everything. — Verdy_p (talk) 20:54, 2 March 2018 (UTC)
Thank you for all those details! :-) So, I understood: rows on separate lines consume much more CPU than a row on one line, okay. I think I saw such a stats page before, but forgot it, do you have a link for me? That would be great! If the old page is a good DOS target, isn't the page version which is still in history still a good target? --aseerel4c26 (talk) 21:07, 2 March 2018 (UTC)
Yes the old page in history is a possible DOS target, but such repetitve inspection of histories by remote bots is very unlikely I think (this could be avoided by forbidding inspecting the history by non logged-in users). But we could also ask an admin to redact some old breaking versions to hide them completely from the history.
Note: the most interesting statistics are within the "content" section of the generated HTML (you need to look at the HTML with your browser console, it is hidden in HTML comments and not rendered on the page), which also contains caching info and profiling info about the most costly operations. There are other reports from the MediaWiki API. — Verdy_p (talk) 21:12, 2 March 2018 (UTC)
Note2: separate cells on separate lines do not cost a lost, but it exists in the lexer (basically within the complex regexps to handle non significant whitespaces) and in the parser (because it handles newlines specially). But when there's no reason to split cells of the same row on separate line because thre table content is more easily viewable in the editor when you do not need to do that, and there are few cells on the row, and the editable line remains short and columns almost aligned (with no need to do any kind of indentation for vertical alignement, and no excessively long lines, such table should be economic, notably if they are generated by bots: before submitting giant data table on a page, you first need to do that an a small extract, see how it is best editable, and can be optimized, then you can tune your generator/bot to do things cleanly. If the page ias actually never meant to be human editable and only generated by bots repeatedly (e.g. with a daily, weekly or monthly report), you should compact the code as much as possible without unnecessary whitespaces.
As well it is always more economic to use the wikisyntax for tables, and lists, because it uses far less resources to parse the page. MediaWiki can then generate the HTML on the fly without difficulty. What is critical is the size in caches, the number of visited (lexer) nodes, the number of expansions, the expansion depth (depth of curly braces for templates or parser functions), and you nave to know in which cases some template parameters are expanded or not (#if and #switch are smarter than you think, they implement shortcuts to avoid the conditional expansion of their unused parameters, but their expansion is not cachable, while template expansion is cached using the effective tempalte name, and its effective parameters, independantly of the intertnal complexity of the template itself; there are some adiditonal conditions such as the detection of conditions that vary over time, such as the use of currenty date time, or costly functions like PAGEINCATEGORY: whose result is not cachable and will require expansion at each invokation; template expansions may be cached for visiting multiple pages using the same parameter values for the same template).
The cachability of template/function expansion offers extrmely significant speed improvement and saves lot of resources on the server, notably this one which is hosted on a modest architecture. I've past considerable time trying to reduce the hidden costs of frequerntly used templates, they are faster now than ever, even if they handle many more cases (notably those used for i18n which are extremely complex because they need also to preserve some level of compatibility for long periods of times, often more than one year, or just to allow a transition to a better/faster system). This is not easy to do on this wiki becaue it has very few extensions (no Lua modules for example), and some of its existing extensions, developed and installed locally, are completely broken : e.g. the slippy maps. — Verdy_p (talk) 21:32, 2 March 2018 (UTC)
Sure page versions can be hidden, I just wanted to make sure I have understood that correctly. I think we do not need to proactively hide here.
Thanks, found the section NewPP limit report. In the HTML source.
Table syntax readability is the most important, great when there is a way which also has a lower cpu cost.
Thank you very much for all your optimizations, that is really needed in this wiki. E.g. I frequently use DE:How_to_map_a which takes a feeled minute to load - likely again due to the many templates on it. Confirmed by the "Transclusion expansion time report". But the tag formatting is very useful. --aseerel4c26 (talk) 22:44, 2 March 2018 (UTC)
Giants pages like "Hos to map a" or "Map Features" are a big problem (it's why TagInfo was created innstead to collect info from many pages and assemble the whole). I think both pages should be deprecated or rewritten another way to find relevant info. But it's also the reason why we've started to restructure the wiki so that individual pages can be more easily found: most of the job this requires is to resolve the zillions red links, for that we need accurate categories, and want to make sure that categories are well structured and items are precisely located with accurate terms. This then allows the internal search engine to find more accurate and more selective results, and helps users find relevant links.
As well being able to manage the translations (that are necessarily incomplete for all languages) is extremely important to avoid mixing everything : I spend lot of time categoizing languages properly and make sure they have the same structures across all languages (here again this further helps the navigation, we can find fallbacks, but are not required to navigate only in English-only pages and we have more contributors in the world to assist in documenting things. Now taginfo also helps making this cleanup.
I've managed priorities on what was the most wanted on the wiki and reported by MediaWiki itself. I study these reports and make lot of searches on the wiki and discover many pages that have been left abandoned or nearly unreferenced and I reconnect them to the whole. With all what I did, the wiki is much less a haystack it was about 2,5 years ago when I started this huge job (which is still not finished). We lack people to do this cleanup, but when I say "cleanup" I dod not mean that I delete content! No I reconnect the contents and make sure all can be found or archived, or that pages for the same topic can be optionally merged and discussed. Another thing which is largely in work is the creation of "groups" in Tag and Key description pages. Basically they are categories supported by a generic description page for several related topics: this in fine could replace the non-workable "How to map a" or "Map features" which are now unmaintainable (too many things in them, as if one wanted Wikipedia to sover everything in a single article...).
Verdy_p (talk) 09:28, 3 March 2018 (UTC)
Quick find-ability is a very good aspect of DE:How to map a because you can use your browser's in-page search. Jumping between results is blazing fast (F3) and you directly see a full screen page full of context. I would not regard this huge page as non-maintainable (look at its history). However, if the page takes a minute to load it is non really that helpful anymore (+ the needed server resources...). Thanks for the cleanup!
Happy mapping (and wiki-ing). --aseerel4c26 (talk) 10:08, 3 March 2018 (UTC)
PAges that take a minute to load and several minutes to generate on the server (including when editing them to add/fix things) are very bad. Mediawiki has other tools to search content: categories, and the search bar at top of all pages. I think it is the way to go. My feeling is that "How to map a" and "Map features" will in fine be deprecated, as they are unmaintainable, so that's why I did not make lot of efforts to make them work better and load faster, I've just ktp them as they are, knowing that they fail in many cases (and are signaled as failing by MediaWiki itself, due to the limits reached). So I do not take any priority to solve these two pages (and their translations), I know they don't work and later they will be removed, or largely simplified to not cover so many tags, by becoming more selective (or by integrating some addon to generate the content). Such integration of external tools was started quite recently on TagDescription pages, where the content is actually fetched by a javascript using an external tool from TagInfo, but only in the English pages for now. But this integration causes accessibility features for all users that have Javascript disabled in their browser (they just see "loading content..." or "content not available, javascript required" when they try to look at the English documentation; instead they have to view the doc on the TagInfo site and not on the wiki itself, and they cannot edit these descriptions on the wiki with a working preview). — Verdy_p (talk) 11:15, 3 March 2018 (UTC)

Issue with ElementUsage template

I noticed an issue with the ElementUsage template, which can be seen for tags with onRelation=yes, such as Key:colour. Instead of showing an icon, the text "may be used on relations" is shown. Somehow, the template tries to load an image Osm_element_relation_.svg, which does not exist due to the excessive underscore character right in front of ".svg". The template should derive the image filename Osm_element_relation.svg - no idea where this comes from... Added you as you were the last modifier of said templates. Mmd (talk) 17:56, 9 March 2018 (UTC)

This was a glitch for only a couple of seconds second between two edits (made yesterday). Refresh the page it should already be OK when you post this message. Oh I see, this still affected one icon, I just fixed it: there was an extra unwanted space in the template using some triock of Mediawiki that are likely to become unsupported (or supported for compatiblity in more limited cases which require slower code, more complex parsing, and more memory used on the server).
Thanks a lot for the quick fix, the page looks good now! 19:36, 9 March 2018 (UTC)
Sorry for the disturbance I checked it again and forgot one case (this is part of a work needed to fix performance problems on the server, and large pages not rendering correctly or causing excessive delays, long response time, and unnecessary workload on the server; these workloads don't necessarily break pages only a few, but still they are a longterm problem of maintenance; here it was quite "simple" to handle, but sorting problems one by one helps solving more complex cases progressively).
This server has stronger limitations thant those used by Wikimedia. Sometimes workarounds are hard to find. We can see some hotspots in performance. Basically I want to have some heavily used templates to render in less time (I've done that to make some templates working 10 or 20 times faster: these being eliminated, we see other hotspots promoted and depending on something else. Whe nwe resolve these, we can then enhance templates to support more cases (notably internationalisation, tracking common errors, better usage of templatre expansion caches, reduction of dependancies, unification of the structure of the wiki, improved linking, better categorization, better maintenance of many forgotten pages left unmaintained that are hard to find even in their own native language because they were only used in one link in a page where the link was no longer relevant...)
There's lot to do to fix old things on the wiki and maximize its capabilities and performance and generalize the concepts/methods to avoid similar errors later (we've accumulated really a lot of undetected errors over time, with lot of duplicated efforts for the same thing due to lack of coordination across contributors that did not, and could not, know that some topics were already partly covered somewhere else). Slowly the haystack finds a structure using existing usages as much as possible (these usages have to be regularized, even if this requires some adaptation for compatibility and possible smooth migrations of older practices that were found to be less easily maintanable).
Verdy_p (talk) 19:25, 9 March 2018 (UTC)

Route relation: Roles forward:stop:<number> etc. on page Relation:route

Dear Verdy p,

in the following I'll be referring to this edit: Could you please name an example where they are used in Public transport (esp. PTv2). The page says that these tags are being used for PT-routes which seems outdated to me. Thx, U30303020 (talk) 14:30, 11 March 2018 (UTC)

You're alone and this order specified by numbers, rather than just the unstable order of members which is unmaintainable in editors (notably in iD!) and all relations where the order of members is not significant at all.
These numbers are there since the begining of the specifications in 2007 and is still needed in various cases (because of ambiguities for routes that perform local loops or pass twice on the same stop for a single main "direction" after branching).
"Unlikely" does not mean it is not used and not needed. In fact there does exist cases where this is the only way to represent the order correctly, and without having to add the same member twice with the same role! And even with PTv2 (where forward/backward is no longer needed when we separate directions using "master" relations) we still need to specify an order, including for route ways (not just stops and platforms) ! Otherwise the order is completely unpredictable (routes are actually more complex than the most frequent simple cases you're thinking about: more rare cases are also valid and your "unlikely" argument is clearly violating rules that have been validated since the begining; PTv2 does not remove these complex cases but expose even more why we need an explicit order !). OK the API can preserve the order of members wince v0.6, but editors do not preserve order or do not let users specify it (except in JOSM).
Note: initially an underscore (_) was used instead of the colon (:) before the number, the colon was decided rapidly after (there may remains some tags still using the underscore).
You cannot suppress such tags from the doc that have been there since more than 11 years, without asking why we still need them and waht we can do when we need a precise order (including explaining that iD, used by most OSM contributors, does not preserve the order of members in relations and still does not allow specifying it).
Summary: PTv2 just drops the need to distinguish "forward" and "backward". It adds new roles suffixes: "entry_only", "exit_only", it does not remove the need to specify the order which exists since the beginning and remains needed.
Almost all relations in OSM have been designed now so that the order of members is NOT significant, and when order is needed we have to use explicit tagging (or roles), and their existence is justified and are not "errors" as what you think by considering only the most frequent simple cases!
So before performing such deletion, it has to be discussed seriously, and caveats must find a way to resolve them (for now there's not been any other proposal and documentation about these solutions, including in Germany where you are just starting recently to work with OSM). — Verdy_p (talk) 14:37, 11 March 2018 (UTC)


Hi Verdy P, thanks for correcting it correctly. The category was linked incorrectly because when you clicked "Users in the Netherlands" in WikiProject Netherlands you got a category page with just one user. And yes, my corrections did not seem to do a whole lot of difference. --Mdeen (talk) 08:45, 19 March 2018 (UTC)

No all templates were using the lowercase article, until you or someone else ade an error while modifying the User box to have an undesired uppercase. Look at the category in question it has been filled correctly since long by users already using this userbox. I undid that undesired change that broke everything. Ther's a lowercase everywhere for the article, in all templates.
The WikiProject page was also doing things correctly until someone misused a parameter there. You were the only user that had made a use with a capital after doing this change, nobody was affected by what you thought was an error, that had been prevented since long. That's why I undid your move as it broke for everyone else than you. — Verdy_p (talk) 08:48, 19 March 2018 (UTC)