Difference between revisions of "Wikispooks talk:Standardisation"
(capitalization) |
|||
Line 5: | Line 5: | ||
:It bothered me for a long time that use of capitals is inconsistent in SMW... SMW requires for example "money/'''C'''reation to link correctly, money/creation does not work. I propose for the interests= , constitutes= etc. fields to use '''M'''oney/'''C'''reation. Whatever form we decide to use, it should be consistent. This would underscore nicely the high encyclopedic quality we have managed to achieve so far. :) [[User:Urban|Urban]] ([[User talk:Urban|talk]]) 02:28, 20 February 2022 (UTC) | :It bothered me for a long time that use of capitals is inconsistent in SMW... SMW requires for example "money/'''C'''reation to link correctly, money/creation does not work. I propose for the interests= , constitutes= etc. fields to use '''M'''oney/'''C'''reation. Whatever form we decide to use, it should be consistent. This would underscore nicely the high encyclopedic quality we have managed to achieve so far. :) [[User:Urban|Urban]] ([[User talk:Urban|talk]]) 02:28, 20 February 2022 (UTC) | ||
+ | |||
+ | ::[[MediaWiki]] automatically capitalises the very first letter of page titles, so "money" and "Money" are indistinguishable to the software a level below SMW. This is ''not'' true for letters that immediately follow a "/" in a title, hence the call to set a standard to prevent broken links. We have [[Template:Capitalize]] which could automatically capitalize the items in a list before making links. So whether the source showed [[money/Creation]] or [[Money/Creation]], it would display as the latter. Sound good? This shouldn't be too tricky, especially as I'm looking again at templates at the moment. -- [[User:Robin|Robin]] ([[User talk:Robin|talk]]) 10:26, 20 February 2022 (UTC) | ||
==Sub pages== | ==Sub pages== |
Revision as of 10:26, 20 February 2022
Page case
Mediawiki automatically capitalises the first letter of page titles, but for multi-word titles, case is an issue: "False Flag Attack", "False Flag attack", "False flag Attack" or "False flag attack"? Sometimes a capital is obviously required (e.g. for names), but otherwise it is ambiguous. SMW is pretty good at handling redirects, but still, it's worth having a policy on this. I propose to use small letters where there is no reason not to - in other words, to follow the Wikipedia standard, for reasons both of simplicity (easy to define) and compatibility (software such as Wikipedia+ might benefit from noticing the 1:1 correspondence). Opinions? Robin (talk) 05:17, 3 March 2014 (GMT)
- This has been an issue pretty much from the start. It would be beneficial to agree a standard and what you propose is OK by me. There has always been a similar issue with categories over singular/plural names. That is declining in importance with the rise of SMW but I nonetheless concluded long ago that new categories should always be in the plural - not explicitly stated anywhere though --Peter P (talk) 06:14, 3 March 2014 (GMT)
- It bothered me for a long time that use of capitals is inconsistent in SMW... SMW requires for example "money/Creation to link correctly, money/creation does not work. I propose for the interests= , constitutes= etc. fields to use Money/Creation. Whatever form we decide to use, it should be consistent. This would underscore nicely the high encyclopedic quality we have managed to achieve so far. :) Urban (talk) 02:28, 20 February 2022 (UTC)
- MediaWiki automatically capitalises the very first letter of page titles, so "money" and "Money" are indistinguishable to the software a level below SMW. This is not true for letters that immediately follow a "/" in a title, hence the call to set a standard to prevent broken links. We have Template:Capitalize which could automatically capitalize the items in a list before making links. So whether the source showed money/Creation or Money/Creation, it would display as the latter. Sound good? This shouldn't be too tricky, especially as I'm looking again at templates at the moment. -- Robin (talk) 10:26, 20 February 2022 (UTC)
Sub pages
Mediawikis usually support subpages of the format "Main topic/sub-page". This doesn't seem to be working here - it's probably a PHP variable. Possibly it got switched off to prevent confusion as regards pages like "9/11". Although that is an excellent name for a page, it conflicts with the sub-page standard, and I suspect we may wish to use sub-pages to give structure to articles in conjunction with SMW. For example, EVENT/PERPETRATORS, EVENT/CUI BONO?, EVENT/EVIDENCE, EVENT/MEDIA COVERAGE possibly in conjunction with a more systematic approach to properties. i.e. (EVENT has perpetrators EVENT/PERPETRATORS) or some such. This is still just a hunch at this stage, but some sort of policy on subpages would probably be a good idea in any case. Robin (talk) 19:34, 2 January 2014 (GMT)
- Sub-pages are turned off by default in the Main NS see Help:Subpages and more complete discussion here. I agree it would be good to enable them in MAIN too. Problem is the "/" is disallowed in pagenames where it is turned on and we have quite a few existing ones - mainly 9/11 related. There are also a few categories using it. All would have to be renamed leaving no redirect. That would screw up links to our most visited existing page (9/11:Israel did it) but I guess that's a small price to pay for the extra functionality provided. Need to cogitate about how best to implement this --Peter P (talk) 20:00, 2 January 2014 (GMT)
- I say turn it on and see what happens:) I should think it won't be more complex than just moving the pages. Might make for page titles such as 9-11/WTC7/Collapse/Media Blackout. We could probably just redirect "9/11:Israel did it" to 9-11/Perpetrators/Mossad. As for policy, perhaps aim towards a policy that subpages should only be used in conjunction with SMW. This may in turn help provide more suggestions for useful properties. SMW is so open ended that I'm finding it a real help to have some content to work to fit into it. . Robin (talk) 20:36, 2 January 2014 (GMT)
- Done. Added just NS:Main only for now (ie that is the only change made to the default install sub-pages setup). No discernible affect on the existing 9/11 pages that I can see yet. Sidebar menu appeared broken when displaying existing pages with "/" at first (only showed the top 'Navigation' section) but that seems OK now. I've cleared the cache for the pages tested too. I suggest we proceed with considerable caution on this. A proliferation of sub-pages could become as problematic as with categories - limiting it to use in conjunction with SMW properties seems sensible - to begin with anyway --Peter P (talk) 07:50, 3 January 2014 (GMT)
List Of Subpages
I'm not sure quite where this is going, but it might one might one day evolve into a machine readable/generatable framework - integrated with matching properties.
Please add to this list as appropriate:
- PERSON/Assassination (e.g. John F. Kennedy/Assassination)
- EVENT/Cover-up
- EVENT/Cui bono?
- EVENT/Media coverage
- EVENT/Perpetrators (e.g. John F. Kennedy/Assassination/Perpetrators)
- EVENT/SUBEVENT (e.g. 9-11/Air Defence) ~ Property:has SubEvent?
- EVENT/Origins or /Background (e.g. World War I/Genesis)
- EVENT/Official Narrative (e.g. Lockerbie Bombing/Official Narrative)
- EVENT/PERSON - for a particular person's involvement in/relationship to an event?? Or is PERSON/EVENT preferable ??
Avoiding Repetition
A page such as "The origins of World War One" is clearly a sub topic of "World War One", so "World War One/Origins" makes sense, but "The origins of World War One" is in some ways a more appealing title, although less amenable to parsing by software. I guess either is fine, so we just need to avoid "World War One/The origins of World War One". SMW is quite sensible at handling redirects in page type properties, though I'm not 100% familiar with its behaviour and it may still be subsequent to change. Robin (talk) 04:31, 9 February 2014 (GMT)
Descriptions
I suggest that a bunch of human readable summaries may be a good next To Do - not least because, if they're free of pagelinks (maybe useful for technical reasons?) it is independent of and standards set as regards pagenames, capitalisation etc. So they won't need revision if we update templates/SMW patterns etc. which seems likely. A couple of sentences to give an overview and appear either as tooltips or on the right of a table made by SMWDocs. I'm thinking that every page in the main namespace has probably got a use for a description - which could even be displayed at the very top, a kind of super lede. Not sure on that, but it's a worthwhile activity now. I think I'll rejig the "To Do" pages to display it prominently. Robin (talk) 20:36, 2 January 2014 (GMT)
- That would fit in a whole bunch of pages I'm mulling as existing document subjects (ie Property:Is about) and which don't exist yet. I don't want to get bogged down on full expositions when there are so many needed. Better to make them stubs, started with the sort of summary you have in mind and to add similar summaries to obvious existing pages too. I reckon I could make rapid progress on that as a project. --Peter P (talk) 21:06, 2 January 2014 (GMT)