From Abulafia Random Generator Wiki
Jump to navigation Jump to search

Remove “cap” versions?

Having the “Cap” versions of the same tables are redundant, and users could easily capitalize the results if they want, using the MediaWiki Parser Functions, like this <sgdisplay iterations="1">{{ucfirst:[Color.all]}}</sgdisplay>, which gives: <sgdisplay iterations="1" linebreak="false">[Color.all]</sgdisplay>. --MidnightLightning 10:10, 24 April 2008 (PDT)

They could do that for individual calls, but right now there’s no way for them to do that if calling from another table. Since this is essentially a utility table meant to be called from other tables, we’ll need an inline way of calling for caps without relying on wikicode. Hope that makes sense. --Dave Younce 04:12, 26 April 2008 (PDT)

What? I guess I don’t understand what you mean by ‘inline without relying on wikicode’. The example I gave above is a way to call it from another table, inline. Why does it have to not include wikitext? For example, on this page (which is not the main “Color” page, so can’t use the table names directly), if I want to have a capitalized color, I could put “<sgdisplay iterations="1">[Color.allCap]</sgdisplay>”. Instead, I could use the line <sgdisplay iterations="1">{{ucfirst:[Color.all]}}</sgdisplay>, which gives the same result. Yes this line is slightly longer in code and mixes ‘sgdisplay’ code with wikitext, but it’s universal (the “Color” generator may use the “[table]Cap” syntax to name the uppercase tables, but other articles may use the “[table]_cap” or “uc-[table]” syntax to name those tables; {{ucfirst:[table]}} would work for all of them), and would reduce the number of tables in the utility generators (thereby reducing the work of editing those tables afterward; if I want to add a color to the “bright” group here, I have to make sure I add it to both the ‘bright’ and ‘brightCap’ tables). You’re obviously the admin here, and can set the precedent, but what should that precedent be? Should each article have separate tables for capitalized/lower-case versions, or should the ucfirst parser function be encouraged? --MidnightLightning 08:35, 20 July 2009 (PDT)
Oh, I think I see what you were saying: that you didn’t think that wikitext would work within a <sgtable> block, in addition to within a <sgdisplay> block? Take a look at User:MidnightLightning/Colors, which I created that has a sgtable block that uses wikitext to format the output. You can’t use square brackets to link to another page (external or internal) within a sgtable block, but other wikitext formatting options seem to work just fine. --MidnightLightning 08:43, 20 July 2009 (PDT)

Cool. I’m glad to be wrong on that one and glad it works. I don’t see any need to go back through existing tables and eliminate capitalized table versions (since someone somewhere might already be calling those and it might be a pain to track down all the dependencies) but I agree that we shouldn’t need separate capitalized versions from here on out. Is that what you’re after? -Dave Younce 15:47, 20 July 2009 (PDT)

Cancel that. If it works in all cases, let’s work on phasing out old Caps tables and replacing them with calls to the parserfunction - you’re right that from a maintenance perspective it’s superior. --Dave Younce 16:09, 20 July 2009 (PDT)

  •  BEST PRACTICE  in the 6+ years since the last note, it has become clearer that, for any material that needs to appear in varying cases, it is usually better to retain the mixed-case version, and rely on {{lc:}} for all-lowercase. This is due to the many unpredictable vagaries of capitalization vs. the relative simplicity of lowercasing. --MikeyD (talk) 17:39, 8 September 2015 (PDT)
  •  FEATURE REQUEST  a handy adjunct table for this color table could be the matching adjectival forms—i.e., for the colors “blue”, “cream” and “gold”, the adjectives “bluish”, “cream-colored” and “golden”. This may well be already being done elsewhere; an enterprising user might search the codebase to check … --MikeyD (talk) 17:39, 8 September 2015 (PDT)