Difference between revisions of "Doom Wiki:Central Processing/2015"

From DoomWiki.org

(Admin Rights Movement: new section)
(Admin Rights Movement)
Line 117: Line 117:
  
 
To continue a discussion that spawned [[User_talk:Gez#Machine_Gun_move|here]]: let's discuss which rights [[Special:ListGroupRights|admins currently don't have]] that they really should. For a start, suppressredirect. Any right that corresponds to actions that can already be done in a different way (here: move then delete the redirect) has no reason to be denied. --[[User:Gez|Gez]] 19:39, 3 April 2014 (UTC)
 
To continue a discussion that spawned [[User_talk:Gez#Machine_Gun_move|here]]: let's discuss which rights [[Special:ListGroupRights|admins currently don't have]] that they really should. For a start, suppressredirect. Any right that corresponds to actions that can already be done in a different way (here: move then delete the redirect) has no reason to be denied. --[[User:Gez|Gez]] 19:39, 3 April 2014 (UTC)
 +
 +
: Actually, rereading that page, I don't see anything else matching your last sentence (anyone please speak up if I missed one).  Additional rights defined by MediaWiki, or extensions, but currently *unused* might be more interesting.    [[User:Ryan W|Ryan W]] 23:36, 3 April 2014 (UTC)

Revision as of 18:36, 3 April 2014


Archived discussions

Rquotes

I added Template:Rquote from Wikipedia, where it is deprecated and use is discouraged, but I personally like the style of it and think it would be a good way to do quotes on this wiki where we have slightly less formality. Opinions? --Quasar 00:28, 4 January 2014 (UTC)

I suppose it'd fit for things like the level descriptions lifted from Hexen 64 (e.g., "In these frozen caverns, relentless ice [etc.]" in Guardian of Ice) and maybe for NPC pages (like Jack Campbell), though they're already using Template:Quote. --Gez 08:07, 10 January 2014 (UTC)
I prefer the Template:Quote style for those top-of-the-article quotes. This was an idea for extended quotations from literary sources or people that are within the article text itself. --Quasar 17:57, 13 January 2014 (UTC)

Stubs

I am finding more and more articles that are marked as stub status but contain more or less all the information that can be said on the subject. I am starting to remove stub status from some of them, but it's way more than I can handle. I'd request that if you come across any articles which have been substantially fleshed out but still have an ugly stub header at the top, take the time to remove it. A perfect example and one I just fixed was the Delta Complex map article. All of its sections are filled out with information and I don't know much else that could be added to it but it was still marked as a level stub. --Quasar 19:30, 29 January 2014 (UTC)

Did some shoveling.  I think "more or less all the information" is often subjective, especially for a non-technical topic like a person.
Quasar, given your post above, what do you think of these articles?  I created them years ago, then tagged them as stubs after some people complained that they were very sparse.
Ryan W 02:56, 3 February 2014 (UTC)
The first looks significantly complete. The other two have empty sections. Those sections should either be filled out with info, or removed if the sections are irrelevant. Until such happens I'd consider them to still be level stubs. --Quasar 17:35, 4 February 2014 (UTC)

Captchas broken again

Somebody sold us out through Mechanical Turk again more than likely. As I don't feel like spending the next year blocking the entire Indian subcontinent, I've switched over to some randomized QuestyCaptcha code I found on the Internet. Let's see if it performs any better. --Quasar 15:27, 6 February 2014 (UTC)

A recent series of registrations by users with regex-pattern-matching user names who subsequently make no edits has made me suspicious that the new code, which included a random "Please tell what the current day of the week is in GMT" option (with link to Google) is susceptible to a dictionary attack or possibly even bots with AI coded to be able to answer that particular question. I have modified the code in LocalSettings again to remove that option, so we are currently only using questions that ask for a random character from an MD5 substring that's calculated on a GUID seeded with output from mt_rand. I will continue to tweak and strengthen the code if it proves necessary. --Quasar 17:12, 2 March 2014 (UTC)

Moving pages

I just noticed I can move some pages but not other ones for no reason I can notice. For example, I can move Mancubus fireball clipping but not Blood. Why so? --Kyano 10:12, 3 March 2014 (UTC)

Good question.  It appears to be a result of FlaggedRevs configuration.  By default, after a page has been reviewed (at any level of quality), only admins can move it.    Ryan W 01:42, 4 March 2014 (UTC)

Incidentally, the move of this page was never properly reversed, so all prior edits look like they pertain to the /2013 subpage.  Does anyone know how to fix this without erasing author attribution for any edits?    Ryan W 06:54, 13 March 2014 (UTC)

I'm afraid that ship has sailed, particularly since this page has been edited repeatedly since. I don't think it's that big a deal though. --Quasar 14:15, 13 March 2014 (UTC)

Images with an incorrect aspect ratio

In the following days, I will fix most if not all of the images in the "Screenshots using an incorrect aspect ratio" category. Speak now or forever hold your peace. --Kyano 22:17, 5 March 2014 (UTC)

One thing to watch out for would be any that are actually widescreen shots and are correctly rendered. I know the shot of Eternity on the Eternity Engine page had been mistagged as being incorrect aspect ratio at one point (it is in 16:10 widescreen IIRC). How many shots are we talking about? If I have time, I can help by reviewing them for issues like this. --Quasar 01:38, 6 March 2014 (UTC)
(edit conflict)  There are 199 images in the category.  It's true that the tagging was probably done based only on the dimensions of each uploaded file.  That said, I see a bunch of my ancient E1/E2 walkthrough snaps in there, which are probably safe to batch up.    Ryan W 01:59, 6 March 2014 (UTC)
My original idea was to just resize 640x400 to 640x480 and 320x200 to 320x240 and leave the rest untouched. That should be safe enough. Most of the images in that category with that problem have that size. If there's something wrong it can always be reverted. What do you think? --Kyano 13:11, 6 March 2014 (UTC)
Based on discussion ongoing here at File_talk:Tuttifrutti.png I am going to ask that you hold off on this for the time being. It's becoming quite clear that there are a number of exceptional images that are not classifiable only by their logical aspect ratio or dimensions and have been placed into this category incorrectly. --Quasar 16:27, 12 March 2014 (UTC)
Quasar, I saw your IRC posts.  Nobody said I was an authority on the technical characteristics of rendering :>   but the key thing is that categorization was done haphazardly, a few images at a time, by people with varying degrees of expertise themselves.  So in addition to what you say, there might be hundreds of *un*tagged files needing fixes.
Trying to be constructive here... um...
For certain uploaders, it may be on the record or really obvious which port was used (e.g. Ducon and myself).  For the others, if we could define a reasonably accurate "decision tree" for identifying the common situations you mention, we could re-sort, then talk about mass resizing.    Ryan W 04:06, 13 March 2014 (UTC)

Well here are the guidelines I'd stick to if you want to make progress without damaging any files that shouldn't be resized:

  • The dimensions should be 320x200 or 640x400 to be an immediate candidate. It's very likely anything else was rendered by a source port (which doesn't automatically mean they are correct but that they need more careful treatment, see below).
  • If the image is 320x200 or 640x400 but has a correct-looking (non-squashed) HUD, or sprites that look tall instead of broad (ie they do NOT match their appearance if extracted from the IWAD and viewed on a square-pixel display) then its been rendered with inherent aspect ratio correction by a source port. One of the ones we found and I was talking about on IRC was such a pic, at 640x400 size. It was basically rendered like 16:10 widescreen would be correctly rendered (wider FOV, rescaled HUD that looks tall instead of fat).
  • Just to be clear, as this category is already covered by my first suggestion, the "looks fat instead of tall" thing only works for shots that are 16:10. If the pic is already 4:3, like the one linked above, you can't correct it by rescaling - I suspect that one in particular is a Doom 95 shot and it renders its 4:3 modes in a very odd manner. You won't fix these by rescaling them.
  • It's still worth considering, for 320x200 images in particular, that a loss of quality is incurred by rescaling them to 320x240. This particularly hits numbers on the status bar, and port elements like the BOOM HUD, badly. I feel uncomfortable with the idea of introducing tons of scaling artifacts in the name of chasing after proper aspect ratio as an ideal. It's not necessarily the most important thing about the pics we have in some cases, I think.

--Quasar 14:06, 13 March 2014 (UTC)

I seem to recall a couple of my shots being redone with professional tools, i.e. cropping the HUD and then pasting it back in, with no apparent artifacts in the final copy.  Any media editing is inherently labor-intensive though, as exemplified by the manual check in your second bullet point.  Maybe the next logical step is a bot that reviews new image dimensions and warns the user before they upload 150 more?  :P      Ryan W 17:52, 13 March 2014 (UTC)

Source extension

I guess we need to have a debate on whether we want to keep/use the source extension. It seemed like something that would be very useful on an often highly technical wiki like this during the install process, so it was one I specifically selected for addition. I didn't know it had compatibility problems with wiki markup though. That's a bit discouraging. I have also run into problems with finding any method of imposing a right-hand margin on the code it produces in the past. --Quasar 01:50, 6 March 2014 (UTC)

The incompatibility is easy to understand as instead of merely telling MediaWiki the text block should use monospaced font (and respect whitespace), it tells it it is raw code. So interpreting markup elements would generally be undesirable. For a pseudocode example:
<source lang=php>string $foo = '\ . $bar . '\;</source>
string $foo = '\ . $bar . '\;
I don't think we're using a lot of markup in preformatted blocks, though (contrarily to the ZDoom wiki). The edit I reverted just happened to be on one of the few. --Gez 03:02, 6 March 2014 (UTC)
Makes sense, thanks for the input. Would you say you're in favor of keeping the extension around though? --Quasar 03:11, 6 March 2014 (UTC)
I think another solution should be found. While this wiki doesn't have a lot of source code snippets, the ones that there are should have highlighting. If the problem is that it's not possible to highlight portions of code (for example, bugged code, since most of the code snippets are inside the "Errors and bugs" category), work should be done to implement that feature in the source extension. My two cents. --Kyano 10:21, 15 March 2014 (UTC)

<tt>, <code>, etc.

This issue has been raised these last days due to some edits I've been doing. It turns out there are two ways to represent monospaced words/sentences: using either <tt> or <code>.

  • <tt>: that's what's being used in most of our articles now. It looks_like_this().
  • <code>: that's what's used in a few articles. It looks_like_this().

As you can see, the biggest apparent difference between the two is that <code> adds a grey background.

I personally support changing all <tt> occurrences to <code>. There are several reasons from my point of view:

  • <code> adds a grey background, which serves as a visual separator from the rest of the sentence which goes beyond the font (which is monospace for the two).
  • It's what Wikipedia is doing. For example: the Hello world program article. As you can see, they use <code> for all code samples inside sentences. On top of that, the big snippets of code also have a grey background, for consistence.
  • <tt> is currently deprecated and does not exist at all in HTML5. Should MediaWiki transition to HTML5, all <tt> occurrences will have to be replaced. That will not happen today, but it will end up happening at some point.

If the grey background is a problem, it can be removed at CSS level. But, again, I strongly support keeping it. As I've seen there's a habit in this wiki of avoiding the imposition of style policies, but something should be decided in this regard :)

On a related note, there is a bug in the rendering of both tags in Chrome: the fonts of <tt>, <code>, <pre> and the source extension look much smaller than the rest of text. Wikipedia noticed the bug and then fixed it by adding these lines to their CSS file:

<source lang="CSS"> /* Fix so tags look the same in Google Chrome. */ tt {

   font-family: monospace, sans-serif;

} </source>

Thoughts? :) --Kyano 15:00, 29 March 2014 (UTC)

I'd suggest doing what I did on the ZDoom wiki and using a template to wrap these tags. So you replace <tt>blah</tt> by {{c|blah}} instead of replacing it by <code>blah</code>. This makes it easier to update everything at once if needed. Personally, I don't really like the a background color change in text placed within a paragraph, I find it ugly and distracting, and I think the font change should be enough to serve as visual separator. It's why I still use tt instead of code. (On the other hand, if it's outside of a paragraph, then yeah, give it a different background, which is why I wrapped some <source> tags inside a prettytable. --Gez 15:28, 29 March 2014 (UTC)
That's another possibility, suggested by Quasar. At that moment, I thought it would be overkill (like using a template just for bold text), but maybe it's the best solution.
By the way, I think a grey background for <source> should by added with CSS so we don't have to do dirty tricks. --Kyano 20:37, 29 March 2014 (UTC)
I agree with Gez as previous discussed on IRC that <code> with a gray background is inappropriate for single words in the middle of a sentence. It harms readability. BTW I slightly edited your comment to maintain the discussion formatting, Kyano. I favor the template as a long-term solution and I believe it should simply expand to <span style="font-family: monospace, sans-serif;">{{{1}}}</span> --Quasar 21:31, 29 March 2014 (UTC)

Admin Rights Movement

To continue a discussion that spawned here: let's discuss which rights admins currently don't have that they really should. For a start, suppressredirect. Any right that corresponds to actions that can already be done in a different way (here: move then delete the redirect) has no reason to be denied. --Gez 19:39, 3 April 2014 (UTC)

Actually, rereading that page, I don't see anything else matching your last sentence (anyone please speak up if I missed one).  Additional rights defined by MediaWiki, or extensions, but currently *unused* might be more interesting.    Ryan W 23:36, 3 April 2014 (UTC)