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

Key:turn

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 (https://wiki.openstreetmap.org/w/index.php?title=Key:crossing&diff=1547148&oldid=1547144 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)
https://wiki.openstreetmap.org/w/index.php?title=Key:crossing&diff=1547129&oldid=1547126 https://wiki.openstreetmap.org/w/index.php?title=Key:crossing&diff=1547130&oldid=1547129 https://wiki.openstreetmap.org/w/index.php?title=Key:crossing&diff=1547135&oldid=1547130 https://wiki.openstreetmap.org/w/index.php?title=Key:crossing&diff=1547144&oldid=1547135 https://wiki.openstreetmap.org/w/index.php?title=Key:crossing&diff=1547148&oldid=1547144https://wiki.openstreetmap.org/w/index.php?title=Key:crossing&diff=1547150&oldid=1547148 https://wiki.openstreetmap.org/w/index.php?title=Key:crossing&diff=1547152&oldid=1547150 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)

Move

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)