User talk:voidxor

From Wikipedia, the free encyclopedia
Jump to: navigation, search

A discussion on the Linux distribution talk page[edit]

Hello! There's a somewhat lengthy content-related discussion in Talk:Linux distribution § Information on GNU/Linux that would really need input from more editors. It's about an ongoing disagreement on how should a Linux distribution be described, required level of coverage by references, and partially about the way article's lead section should reflect the article content. If you could provide any input there, I'd really appreciate it! — Dsimic (talk | contribs) 03:16, 15 January 2015 (UTC)

Thanks for thinking of me. I have added my two cents on that talk page. – voidxor (talk | contrib) 07:24, 15 January 2015 (UTC)
Thank you very much! I've just described what else is disputed over there, and it would be great if you could, by chance, invest just a little more time to have a look into that. — Dsimic (talk | contribs) 07:39, 15 January 2015 (UTC)
I think I'm burned out on this one, sorry. Free Software Foundation fan boys wear me thin, and the editors that responded after me pretty well hit the nail on the head. – voidxor (talk | contrib) 22:50, 15 January 2015 (UTC)
No worries, normality in the article is already restored. :) Thank you once again! — Dsimic (talk | contribs) 06:04, 16 January 2015 (UTC)

"Upright" parameter for images[edit]

Hello! Regarding your edit on the Nested RAID levels article and my subsequent revert, please see Wikipedia:Extended image syntax § Size; here's a quote from it:

Scale a thumbnail image to 75% of normal thumbnail width, rounding the result to the nearest multiple of 10 pixels.
Adjust a thumbnail's size to Factor times the default thumbnail size, rounding the result to the nearest multiple of 10. For instance, "upright=1.5" makes the image larger, which is useful for maps or schematics that need to be larger to be readable. The parameter "upright=1" returns the same size as thumbnail width, and "upright=0.75" is functionally identical to "upright" alone. If you set Factor equal to the image's aspect ratio (width divided by height) the result is equivalent to scaling the height to be equal to the normal thumbnail width.

I know, the name of the parameter is pretty much contradictory, but before reading the documentation at some point in time I was also under impression that |upright= is to be used only for portrait images. — Dsimic (talk | contribs) 06:37, 1 February 2015 (UTC)

The documentation doesn't say whether it's for portrait images only. My understanding was the same as your initial impression, and I personally don't see anything in the documentation to dispute that, but it is fine as you've put it for now. – voidxor (talk | contrib) 17:13, 1 February 2015 (UTC)
Right, but if the documentation says nothing about the orientation, it's quite reasonable to assume that the parameter applies to all shapes of images. Moreover, specifying the image sizes dynamically is beneficial for displaying them on various devices and with different pixel densities, and there seems to be no other way for doing it other than by using |upright= parameter. I'd be really happy if we could introduce new |scale= parameter for that purpose, for example, but I don't think something like that is going to happen. Hope you agree. — Dsimic (talk | contribs) 17:25, 1 February 2015 (UTC)
After giving this some more thought, I still disagree with the use of |upright= in the RAID articles. Here's why:
  • While the documentation doesn't prohibit the use of the |upright= parameter for landscape images, it doesn't explicitly say that it's appropriate either. The original intention was clearly to tame the size of portrait images, since the default handling (per user preferences) scales images with respect to width. The documentation even suggests feeding |upright= the aspect ratio to maintain a more-or-less constant image area throughout an article.
  • The upright parameter scales the default image size by some factor. However, the default image size is determined by user settings, not screen size! I have my image size set to 300px (the largest) because I have a solid broadband connection and like to see photographic detail. Consequently, the diagrams on Nested RAID levels are now enormous on my SXGA screen—more than half the width of the article. Users with a thumbnail preference of 120px likely have the opposite problem: text that is too small to read. Our settings are not the problem; the problem is that dynamic scaling is being used on diagrams. Unlike photographs, diagrams should not change with user preference; they should be large enough to make the text comfortable to read even on small dot pitch devices like laptops. Therefore, I recommend fixing pixel width on diagrams regardless of whether they're in a landscape or portrait orientation. – voidxor (talk | contrib) 01:18, 3 February 2015 (UTC)
Hm, I hear you, and I agree to some extent. You're totally right and I agree that the sizes of images should be perceptibly constant or comparable no matter where they're displayed, but that unfortunately cannot be done with the means currently provided by MediaWiki. For example, you have an SXGA screen, but please think about how the images would look on a larger screen with a significantly higher pixel density and no "retinal scaling" in place – those 300 or 500+ pixels are no longer taking half of the article width and they actually look tiny. We'd need MediaWiki to support something like what responsive web design does, in order to have consistent image sizes all around – everything else is some kind of a compromise.
Speaking of whether the |upright= parameter should be used only for landscape images, well, that's debatable. For example, documentation also clearly says that it is "useful for maps or schematics that need to be larger to be readable", and surely not all maps or schematics are in portrait shape. I'd say that using this parameter for enlarging thumbnails is some kind of a non-ideal approach, or a parameter naming heritage, but still better than fixed image widths in pixels: if someone has configured larger thumbnails in account properties, that configuration should make default-sized (that is, |upright=1 or omitted) thumbnails readable on a particular screen, and scaling up through the |upright= parameter should still fit rather well. At the same time, we should aim at making articles readable when viewed with default account settings, as that's simply how the vast majority of readers see them. Hope you agree. — Dsimic (talk | contribs) 06:32, 3 February 2015 (UTC)
What we need is the ability to specify image size in non-pixel units of measure, such as 3.5in or 6cm (perhaps even em, en, or ex). Percents of article width would be nice as well. While CSS supposedly supports those units of measure, most browsers and operating systems fail to calibrate them to the screen's resolution and dot pitch. Another academic standard gets perverted by Microsoft and Apple, oh well.
As for the documentation saying that the upright parameter is useful for maps, that's an unsightly hack and not an academically correct use of a markup language, in my opinion. But you probably know more about these parameters than I do, so I'll let you make the call on Nested RAID levels. – voidxor (talk | contrib) 22:05, 3 February 2015 (UTC)
Exactly, specifying the image sizes in "em" units, for example, would fit perfectly – if that was available in MediaWiki, and if it worked properly in all web browsers. I'll think more about the whole thing, and while I'm by no means an expert on MediaWiki, I totally agree that using |upright= parameter for other things is an ugly hack, what was probably opted for to minimize the amount of changes needed for having some kind of dynamically sized images. — Dsimic (talk | contribs) 22:33, 3 February 2015 (UTC)

Train running away[edit]

Re your message, I can give a source but don't know, or don't have the authority, to reinstate my edits. If you can put them back, I'll add a source Chrismorey (talk) 07:03, 3 February 2015 (UTC)

You actually do have the authority, Chrismorey; anybody can undo somebody's recent edit if they have a just reason to do so. Just click the "Undo" link. In this case though, I'll gladly add your contribution back into the article. Please do add a reference sometime in the next few days (otherwise, it's subject to removal again). If you need help doing that, just let me know. – voidxor (talk | contrib) 21:52, 3 February 2015 (UTC)
thanks, citation now done Chrismorey (talk) 00:31, 4 February 2015 (UTC)
Thanks for adding that citation. If you supply references in the future while adding new content to an article, your edits will be far less likely to be reverted. Just a tip. Happy editing! – voidxor (talk | contrib) 06:32, 4 February 2015 (UTC)

Template:Original research section[edit]

I wanted to let you know that I've declined your move request here, not because it's improper, but because we probably ought to keep the history that would be deleted if I performed your move. I've requested help at WP:HD on preserving the history while performing your requested move, since you're right that it ought to be moved. Nyttend (talk) 02:01, 13 February 2015 (UTC)

Thanks Nyttend! But to be clear, are you referring to the history of the redirect? Usually those aren't worth saving. Or are you referring to the history of {{Section OR}}? That shouldn't be a problem either because it will move to Template:Original research section once the redirect is nuked. Keep in mind the move I'm requesting is colloquially known as "reversing a redirect". – voidxor (talk | contrib) 05:02, 13 February 2015 (UTC)
Yes, the history of Original research section. Most redirects' histories consist of creation, retargeting, vandalism, and other technical stuff that we don't need to keep. This one, however, was a separate template for a while, and we ought not get rid of it. WP:HD suggested just moving it to a subpage, so the old template's history is at Template talk:Original research section/Old, and I've moved {{Section OR}} to {{Original research section}} as you requested. Nyttend (talk) 22:23, 13 February 2015 (UTC)