Difference between revisions of "Template talk:Document"

From Wikispooks
Jump to navigation Jump to search
(question update)
 
(26 intermediate revisions by 3 users not shown)
Line 1: Line 1:
==Mandatory==
+
== TODO List ==
  
Would it be a good idea to use this on all items in the '''document:''' namespace?
+
#<s> A parameter |description</s>
 
+
# A parameter |Occasion = |ImmediateCause = |WhatPromptedThis for why these documents came about. e.g. A death certificate tied to a death event
[[User:Robin|Robin]] ([[User talk:Robin|talk]]) 05:22, 29 October 2013 (GMT)
+
# A parameter |Location, useful for speeches.
 
+
# A parameter |ProductionDate
:Yep. I think it would. Not sure how to force it though, bearing in mind there a lot of documents that pre-exist the template and don't currently incorporate it. A form for the template would be very useful though --[[User:Peter|Peter P]] ([[User talk:Peter|talk]]) 08:34, 29 October 2013 (GMT)
+
# Rethinking the |see_also parameter - maybe replace by a set of "relates to" links
 
+
# <s>Date Format Standardisation</s>
== Processing Semantic Dates ==
 
 
 
Semantic wiki does seem to be able to parse dates for its own purposes. Is there a way to use it to convert a randomly formatted date into an ISO-formatted date, so this can be used, e.g. to assign a document to a "YYYY Publications" category?
 
 
 
[[User:Robin|Robin]] ([[User talk:Robin|talk]]) 09:08, 11 November 2013 (GMT)
 
 
 
:I'm impressed!!. There must be a way to use SMW parsing for precisely that purpose and the 'isdate' property is the logical one to do it since it simply identifies any old format as a semantically readable date. I do think it would be better to have a new property [[property:Publication date]] for the documents publication date field though. I'll create it anyway and it can be used if you agree. SMW has a LOT of potential methinks --[[User:Peter|Peter P]] ([[User talk:Peter|talk]]) 09:15, 11 November 2013 (GMT)
 
 
 
::Not at all clear how best to delineate between the best use of categories and properties though - I'm still scratching my head on that one --[[User:Peter|Peter P]] ([[User talk:Peter|talk]]) 09:51, 11 November 2013 (GMT)
 
 
 
:::In fact, thinking about it, it would probably be better to have a property [[Property:Has publication date]] because it would then be a simple matter to search on the year of the publication date, making a separate category for each publication year redundant --[[User:Peter|Peter P]] ([[User talk:Peter|talk]]) 12:24, 11 November 2013 (GMT)
 
  
== SMW properties problem ==
+
=== Description ===
  
Robin - have a look at [[Special:Properties]]
+
A mandatory 3-4 sentence summary of posted documents could make browsing much easier while using automatically tables, e.g. using [[Property:Description]]. [[User:Robin|Robin]] ([[User talk:Robin|talk]]) 06:15, 21 December 2013 (GMT)
  
I knew by certain performance issues concerning the Jobs queue and the SMW factobox behaving irratically that a problem was building. I think I can understand why Wikipedia does not use SMW. I still think it is worth developing its use here, but I want to sort out those rogue properties and understand the irratic factbox issue before creating and using any additional ones --[[User:Peter|Peter P]] ([[User talk:Peter|talk]]) 18:23, 12 November 2013 (GMT)
+
=== Production date ===
  
== DocProv use of the 'RED' Broken template is broken on Iframe pages ==
+
A separate parameter for when documents are made as opposed to when they are published may be needed (e.g. especially for leaked documents). However [[property:Creation date]] already exists - a special property for when pages were created on this wiki. [[User:Robin|Robin]] ([[User talk:Robin|talk]]) 06:15, 21 December 2013 (GMT)
  
Have a looks at [[Document:Getting Access to the Secrets of the Osama Bin Ladin Kill]] and [[Document:During 1917]] for examples --[[User:Peter|Peter P]] ([[User talk:Peter|talk]]) 09:55, 21 November 2013 (GMT)
+
=== SeeAlso ===
  
== Publication date fails ==
+
This is currently freeform text, but where it is used, it tends to be a bulleted list of links. This suggests that replacing text with a more tightly specified semantic markup may be a better way to go, combined with a new property, ~ "relates to". This would allow dynamically built lists and have the advantage that the data was available for other purposes. It might be a good idea to keep a human readable chunk, and make a threesome such as we use for source e.g. |related, |relatedURL, |relatedDetail [[User:Robin|Robin]] ([[User talk:Robin|talk]]) 06:15, 21 December 2013 (GMT)
  
The Construction of ISO8601 dates fails when any of its 3 date components is missing. There are a lot of pages with 'Day' missing and their displayed 'publication date therefore shows an error. This is especially applies to pages with templates which themselves have been changed to include 'DocProv' - The 200YT template pages are an example. There may be others. --[[User:Peter|Peter P]] ([[User talk:Peter|talk]]) 07:45, 23 November 2013 (GMT)
+
== Date Format Standardisation ==
  
== Author - conditional statement ==
+
Semantic wiki seems to parse dates OK for its own purposes, but I'm not entirely happy with its handling of incomplete dates. "2013" =/= "Dec 2013" =/= "1 Dec 2013" and it should be possible to input on of the two former ones if one doesn't know a specific day and or month. It would be convenient and tidy if SMW were good enough at date processing, but at the moment I'm still not sure it is. If we could highlight specific deficiencies (e.g. in Semantic Forms input capabilities?) we could forward these concerns to the developers. [[User:Robin|Robin]] ([[User talk:Robin|talk]]) 06:15, 21 December 2013 (GMT)
  
I've removed the #Ifexist statement from the author variable because it inhibits the [[Property:Is author]]. This way all documents will be browseable semantically by 'Author'. The downside is that Author 'Unknown' gets page-linked --[[User:Peter|Peter P]] ([[User talk:Peter|talk]]) 12:00, 27 November 2013 (GMT)
+
== Form lagging a bit ==
  
== Author notes ==
+
I hesitate to mention this with all the stuff you're doing but 'Form:Document' needs to reflect all these additions sometime soon aswell. --[[User:Peter|Peter P]] ([[User talk:Peter|talk]]) 18:31, 24 December 2013 (GMT)
  
I wonder whether these are needed in light of assigning all authors to a property of type ''"page"''. We could of course change it to type ''"text"'' and revert the template edits to include the ''"#Ifexist"'' conditions again. My feeling just now is that it is probably best to leave it as I just modified it (ie ''"Is author"'' has type page. It is then easy to create the right page and put any bio and other info in it. It would resolve a perennial dilemma I've wrestled with, namely when and if to assign as author to a category and if so whether or not to create a separate page. The way it is now seems much cleaner and intuitive to me. What do you think? --[[User:Peter|Peter P]] ([[User talk:Peter|talk]]) 15:30, 27 November 2013 (GMT)
+
=== Comma separated lists ===
  
:: 2nd thoughts - Leave ''"AuthorDetail"'' as you've done it. It is clearly appropriate on some pages where rank, retired etc etc apply because we don't want them in page names --[[User:Peter|Peter P]] ([[User talk:Peter|talk]]) 17:24, 27 November 2013 (GMT)
+
I'm aware that [[Form:Document]] is lagging. My first priority is to get the underlying data format straight. I see one more technological upgrade for this template on the immediate horizon - the replacement of hardcoded (and limited) numbered lists with comma (or other character) separated lists - which potentially could make for cleaner code and an easier interface. {{t|{{!}}SeeAlso}} needs an upgrade to I'll try it with that. [[User:Robin|Robin]] ([[User talk:Robin|talk]]) 14:39, 30 December 2013 (GMT)
  
== AORAN + Subject ==
+
== Dates issue following recent Forms upgrade to v2.6.1 ==
  
Good stuff Robin. Makes for a much better set of DocType properties.
+
I noticed an apparent bug soon after this upgrade. Tried to track the issue down a couple of times without success. Thought is was the form u-grade but it turns out that was only what made it apparent, in that the form no longer filled in a blank day as '1'. Briefly, if day is not completed, a weird 'expression >' error appears in bold-red, just below the DocProv section of the document. It does NOT happen if only the year is completed, neither if the date in entered in the form  monthname/yyyy by non-form editing. Also, it does not happen if the alternative ISO date params are used with the day left out.<br/>
 +
Not sure how best to deal with this because I reckon it is a pretty fundamental requirement that documents can be reliably created and edited using the form - In fact for new editors it probably ought to be mandatory.<br/>
 +
I'm still a bit distracted with server issues - tearing my hair out trying to get TLS IMAP email working (Dovecot/Postfix). However, since I can still send and received domain.com email OK I intend to shelve it for a bit and spend some time tweeking the Documant form using tabs to separate the mandatory from the various optional/doctype-specific sections.<br/>
 +
If you have any ideas on how to fix that damn bug please have ago. You'll probably get there a lot faster than me anyway. --[[User:Peter|Peter P]] ([[User talk:Peter|talk]]) 13:19, 21 January 2014 (GMT)
  
Also I think it would be a good idea to declare up to 3 subjects (to begin with anyway) per document too - and make each a page link  even if the page does not exist yet. This all has the makings of an impressive browsing and useful-info-finding syste. Will need to apply it to Files of category 'Doc' too. Next thing needs to be a form to enforce all this :-)) --[[User:Peter|Peter P]] ([[User talk:Peter|talk]]) 14:22, 28 November 2013 (GMT)
+
== Reinstatement of FileProv ==
  
== TODO List ==
+
I propose to reinstate <code>Template:FileProv</code> and create a separate form for it. This is in anticipation of moving to a few more dedicated namespaces. Both the form and template will be very similar to the existing ones but a couple of annoying anomalies can be removed - like the 'local copy' parameter and use of  the Document Namespace variable doing odd things to 'File' namespace page edits which bother me and may be storing up trouble. I've put off editing loads of files whilst cogitating about this and would like to get on with them using a dedicated form. I think it would be good to deprecate all those extra subjects in favour of the comma-delimited list approach too. That way a single 'additional info for the entire subject group can be used. It will be much easier to use the form and should produce a clearer display too - though there are pitfalls, notably where existing page names contain commas. That will have to be addressed I guess. Thoughts?  --[[User:Peter|Peter P]] ([[User talk:Peter|talk]]) 16:42, 4 February 2014 (GMT)
 +
:''Namespaces'' - Probably a good move.
 +
:''Commas in titles'' - The current technology (#arraymap) doesn't actually ''require'' use of commas as separators, though it is the most natural character to me, another sequence ''could'' be used. How many pages are there with commas in the title? Unless it's more than a handful, I say keep commas as separators and just botch the titles to exclude that character.
 +
:''Separate template'' - I see no benefit from this. Instead I suggest vary behaviour by namespace with a #if block. This is not hard, and will prevent having multiple copies of code, which is not a good road to go down. What's needed to move forward with this is a list of the stuff to vary by namespace. [[User:Robin|Robin]] ([[User talk:Robin|talk]]) 22:37, 4 February 2014 (GMT)
 +
::OK I guess the 'document' issue is pretty much a legacy one-off anyway. So the principal to adopt is that a template can (in general theoretically and in this case practically) be used for pages in more than one namespace; any differences in usage to be noted against template parameters + conditional display code blocks and reflected in separate form design elements. Form differences in this case will be minor too, since the ''localcopy'' field is required in both - just treated slightly differently but using separate forms will address the red-link auto-form-use issue which I reckon is a big plus. I doubt the ''Comma'' issue is much of an issue at all, especially since pages so listed are likely to be a relatively small sub-set, so we'll stick with commas and see what happens. The template will need another field though - ie a generic description for the subject list. I'll work on all this over the next few days. --[[User:Peter|Peter P]] ([[User talk:Peter|talk]]) 07:21, 7 February 2014 (GMT)
  
I'm happy with how it's working out. No formatting in the pages themselves, do it all in templates - much cleaner. I suggest we keep tinkering with DocProv and see what other improvements we can find, then make a list of them and go through the Documents and do all the changes at once. Some topics to think about are
+
===Differences between file and document use of this template===
 +
*|localCopy = ''Only needed for the {{NS|document}}, should link to an item in the {{NS|file}}.''
  
# Standardising doctypes
+
== Serious Problem ==
# Fixing "source" which combines 2 bits of info. Maybe add |SourceURL and use |Source as a name
 
# Something about original languages and translations
 
# A parameter |Occasion = |ImmediateCause = |WhatPromptedThis for why these documents came about. e.g. A death certificate tied to a death event
 
# |Location for speeches
 
# Publication date as distinct from creation date -- important for leaked documents etc.
 
  
There will still be some (rough) edge cases we can flag up and use to mull over any other work than needs doing. [[User:Robin|Robin]] ([[User talk:Robin|talk]]) 14:55, 28 November 2013 (GMT)
+
I've just noticed that editing existing documents doesn't work - it was broken by the rename because the form system is not redirect aware. This would be a trivial fix if [[Special:ReplaceText]] were working, but it's not. I may see whether I can press [[User:MaintenanceBot]] into service - else we should probably revert back to the old name. [[User:Robin|Robin]] ([[User talk:Robin|talk]]) 22:43, 30 May 2014 (IST)
  
== ToDo + General ==
+
:I have grandchildren staying today and tommorow, so limited time. After I will have a good look  at why 'Text-Replce' is not working and upgrade to latest releases (There have been 3 x MW Mainenance releases since the system was last u/graded - also there is a more recent SMW release) --[[User:Peter|Peter P]] ([[User talk:Peter|talk]]) 06:22, 31 May 2014 (IST)
  
There's not much I can add to what you've done and said already. Great piece of work. I agree all of the ToDo list. Also I notice you've started on the form. With so many parameters and consequent scope for doing something disruptive - for example, accidentally creating lists of properties, a good working form will be a major improvement too. Also, when near done, similar work on the FileProv template would be good. I've added a couple of properties to include much of the existing parameter content in the Sematic properties set up but there is scope for considerably more. It should apply to all files of category 'Doc' --[[User:Peter|Peter P]] ([[User talk:Peter|talk]]) 08:23, 2 December 2013 (GMT)
+
==AORAN change issue==
 +
The last template edit (adding template:AORAN) has caused failure of the document type to display. --[[User:Peter|Peter P]] ([[User talk:Peter|talk]]) 09:12, 31 August 2015 (IST)
  
::Ref item 6 above; we need to be careful about confusing [[property:Creation date]] - a system property for the date the page was created on the wiki - with the creation (as distinct from publication date) of the document that page concerns. --[[User:Peter|Peter P]] ([[User talk:Peter|talk]]) 08:41, 7 December 2013 (GMT)
+
==Question comment==
 +
[[User:Robin|Robin]] I see that the Wikispooks comment is put out of use. I would have liked to use it on two documents of the II, [[cyberwarfare]] related. If I put the whole text in the description it becomes a pretty big box (not looking nice) and I think that from a certain size on problems start to appear (refs missing, text is getting displayed two times). Can you think of something that will work smoothly here? This imo would have been the perfect use-case for the Wikispooks comment thing, but please help me out. Text that I planned to leave there is:
  
== Date issues ==
+
The shortage of qualified personnel to dominate the cyber realm has been noted in the last decade.<ref>https://www.rand.org/pubs/research_reports/RR430.html</ref> It appears that from the proposal of the II an encompassing recruiting effort is now underway by the British government through programs like the: "[[Cyber Schools Hub programme]]", which is meant to get children interested in hacking and related skills for cyberwar.<ref>https://www.dailymaverick.co.za/article/2020-06-02-revealed-the-uks-largest-intelligence-agency-is-infiltrating-british-schools/ saved at [http://web.archive.org/web/20200602101313/https://www.dailymaverick.co.za/article/2020-06-02-revealed-the-uks-largest-intelligence-agency-is-infiltrating-british-schools/ Archive.org] saved at [http://archive.is/85OiT Archive.is]</ref><ref>https://www.dailymaverick.co.za/article/2020-06-04-revealed-veterans-of-the-uk-militarys-cyber-warfare-unit-are-teaching-school-children-how-to-launch-cyber-attacks/ saved at [http://web.archive.org/web/20200604201904/https://www.dailymaverick.co.za/article/2020-06-04-revealed-veterans-of-the-uk-militarys-cyber-warfare-unit-are-teaching-school-children-how-to-launch-cyber-attacks/#gsc.tab=0 Archive.org] saved at [http://archive.is/erAbS Archive.is]</ref> 
  
The new categories of <code>yyyy Publications</code> currently depend on the <code>DocProv</code> parameter <code>DateYear</code>. But both this and the related parameters of <code>DateDay, DateMonth</code> are not supported by <Code>Form:Document</code> and in any case return an error unless all 3 parameters are completed. See [[Property:Has improper value for|here]] for the list of 58 pages currently affected. I was going to pitch in and start editing this list but it may be better to modify the template/form combination to take account of both cases. As things stand, any date entered using the form is not placed in any of the new categories - and I do agree the new categories are useful and involve no processing overhead. Thoughts please --[[User:Peter|Peter P]] ([[User talk:Peter|talk]]) 08:07, 7 December 2013 (GMT)
+
[[User:Sunvalley|Sunvalley]] ([[User talk:Sunvalley|talk]]) 23:59, 4 September 2020 (UTC)
  
:Hmmm, missing data items are probably not going to go away. I've been leaving dates alone as I'm still undecided about them. If SMW can really deal gracefully with missing data items, e.g. "Nov 2013", then just |Date is good enough. However, I'm not sure it can, hence the 3 separate parameters. That is the safest method, since given 3 parameters, it's a cinch to make the full date, but not vice versa. It entails more programming but at least we have a chance to explicitly decide how to handle missing data items. Conclusion:
+
: I deprecated {{t|{{!}}comment}} since I think [[Template:Rate]] is superior for a number of reasons:
#I think I favor the 3 parameter solution unless SMW is proved effective at dealing with missing dates/months
+
:*transparency -- rather than "Wikispooks' comment", it belongs to whoever made it.
#Providing missing data items is always good - some of the Document:s are randomly missing sources and/or dates
+
:*variety -- anyone who wants to chip in a rating can do so, there's no need to give one opinion paricular weight
#Don't do any long and boring conversion jobs by hand. I'm coding a bot at the moment. [[User:Robin|Robin]] ([[User talk:Robin|talk]]) 08:26, 7 December 2013 (GMT)
+
:* simplicity -- together with the rating comes a number (1-5), which facilitates navigation somewhat
 +
: So far, so theory. In practice, ratings are more complex, not working 100% and not yet widely used. However, a fix is probably not so hard, and I still recommend them, for the above reasons. -- [[User:Robin|Robin]] ([[User talk:Robin|talk]]) 17:03, 6 September 2020 (UTC)
  
::SMW does deal gracefully with incomplete dates - see [http://semantic-mediawiki.org/wiki/Help:Type_Date_1.7.0#Handling_of_incomplete_dates SMW help page]. There are maybe 500 pages which currently have a valid SMW date and which would be automatically categorised in the new categories if the year element of the existing |Date parameter where extracted and used on the existing templete. It should be possible with a bit of digging - he says hopefully. Also there are a similar number of pages with brackets around the author + 'An or 'a' in front of the document type - How best to deal with those? --[[User:Peter|Peter P]] ([[User talk:Peter|talk]]) 08:49, 7 December 2013 (GMT)
+
:: Hi, thanks for the explanation. Thought about it, text from "|description" is also copied to other places, so there must be a limitation. "Transparency" is the best point, that is indeed a problem with the (Wikispooks) comment. I will integrate the circumstances in the article. CMS/wiki/server wise I do not know a thing, but would it be possible to use this "|comment" feature under a different name, like: "Additional information", to make it possible again to put in other info for circumstances like this? [[User:Sunvalley|Sunvalley]] ([[User talk:Sunvalley|talk]]) 23:13, 7 September 2020 (UTC)
  
:::It '''is''' possible to extract the year from any valid SMW date - incomplete or not - so long as it contains at least the year element. If there is no 'Year' element it will return the system current year '''See [http://www.wikispooks.org/w/index.php?title=TestDates here]'''. I'll have a crack at this today. If it works OK then the only argument I can see in favour of the 3 parameter format is compatibility with Wikipedia. Thoughts? --[[User:Peter|Peter P]] ([[User talk:Peter|talk]]) 09:38, 8 December 2013 (GMT)
+
::: I did forget about: "|note=", can be used for additional information without using the text space of the document itself. - As for ratings, takes some while until changes are shown on my page and even longer for showing up on the rated page. The last rating of [[Ex-CIA man "kill Putin"]] seems to take even more time than [[MS Estonia]]. As far as text in "|summary=" and "|description=" goes, not sure what it is, but it seems I can not get it to both show up on the rated page at the same time. Anyway, not the priority and my initial concern has a solution. -- [[User:Sunvalley|Sunvalley]] ([[User talk:Sunvalley|talk]]) 18:16, 9 October 2020 (UTC)
  
::::That seems to work OK. All DocProve pages with one or other of the  "Date|" or "DateYear|,DatMonth|,DateDay|" formats completed with at least a year are now placed in a tear category. Looks like it will be OK to not use the latter format any more unless there are over-riding Mediawiki compatibility issues. --[[User:Peter|Peter P]] ([[User talk:Peter|talk]]) 13:05, 8 December 2013 (GMT)
+
==References==
 +
{{reflist}}

Latest revision as of 18:16, 9 October 2020

TODO List

  1. A parameter |description
  2. A parameter |Occasion = |ImmediateCause = |WhatPromptedThis for why these documents came about. e.g. A death certificate tied to a death event
  3. A parameter |Location, useful for speeches.
  4. A parameter |ProductionDate
  5. Rethinking the |see_also parameter - maybe replace by a set of "relates to" links
  6. Date Format Standardisation

Description

A mandatory 3-4 sentence summary of posted documents could make browsing much easier while using automatically tables, e.g. using Property:Description. Robin (talk) 06:15, 21 December 2013 (GMT)

Production date

A separate parameter for when documents are made as opposed to when they are published may be needed (e.g. especially for leaked documents). However property:Creation date already exists - a special property for when pages were created on this wiki. Robin (talk) 06:15, 21 December 2013 (GMT)

SeeAlso

This is currently freeform text, but where it is used, it tends to be a bulleted list of links. This suggests that replacing text with a more tightly specified semantic markup may be a better way to go, combined with a new property, ~ "relates to". This would allow dynamically built lists and have the advantage that the data was available for other purposes. It might be a good idea to keep a human readable chunk, and make a threesome such as we use for source e.g. |related, |relatedURL, |relatedDetail Robin (talk) 06:15, 21 December 2013 (GMT)

Date Format Standardisation

Semantic wiki seems to parse dates OK for its own purposes, but I'm not entirely happy with its handling of incomplete dates. "2013" =/= "Dec 2013" =/= "1 Dec 2013" and it should be possible to input on of the two former ones if one doesn't know a specific day and or month. It would be convenient and tidy if SMW were good enough at date processing, but at the moment I'm still not sure it is. If we could highlight specific deficiencies (e.g. in Semantic Forms input capabilities?) we could forward these concerns to the developers. Robin (talk) 06:15, 21 December 2013 (GMT)

Form lagging a bit

I hesitate to mention this with all the stuff you're doing but 'Form:Document' needs to reflect all these additions sometime soon aswell. --Peter P (talk) 18:31, 24 December 2013 (GMT)

Comma separated lists

I'm aware that Form:Document is lagging. My first priority is to get the underlying data format straight. I see one more technological upgrade for this template on the immediate horizon - the replacement of hardcoded (and limited) numbered lists with comma (or other character) separated lists - which potentially could make for cleaner code and an easier interface. |SeeAlso needs an upgrade to I'll try it with that. Robin (talk) 14:39, 30 December 2013 (GMT)

Dates issue following recent Forms upgrade to v2.6.1

I noticed an apparent bug soon after this upgrade. Tried to track the issue down a couple of times without success. Thought is was the form u-grade but it turns out that was only what made it apparent, in that the form no longer filled in a blank day as '1'. Briefly, if day is not completed, a weird 'expression >' error appears in bold-red, just below the DocProv section of the document. It does NOT happen if only the year is completed, neither if the date in entered in the form monthname/yyyy by non-form editing. Also, it does not happen if the alternative ISO date params are used with the day left out.
Not sure how best to deal with this because I reckon it is a pretty fundamental requirement that documents can be reliably created and edited using the form - In fact for new editors it probably ought to be mandatory.
I'm still a bit distracted with server issues - tearing my hair out trying to get TLS IMAP email working (Dovecot/Postfix). However, since I can still send and received domain.com email OK I intend to shelve it for a bit and spend some time tweeking the Documant form using tabs to separate the mandatory from the various optional/doctype-specific sections.
If you have any ideas on how to fix that damn bug please have ago. You'll probably get there a lot faster than me anyway. --Peter P (talk) 13:19, 21 January 2014 (GMT)

Reinstatement of FileProv

I propose to reinstate Template:FileProv and create a separate form for it. This is in anticipation of moving to a few more dedicated namespaces. Both the form and template will be very similar to the existing ones but a couple of annoying anomalies can be removed - like the 'local copy' parameter and use of the Document Namespace variable doing odd things to 'File' namespace page edits which bother me and may be storing up trouble. I've put off editing loads of files whilst cogitating about this and would like to get on with them using a dedicated form. I think it would be good to deprecate all those extra subjects in favour of the comma-delimited list approach too. That way a single 'additional info for the entire subject group can be used. It will be much easier to use the form and should produce a clearer display too - though there are pitfalls, notably where existing page names contain commas. That will have to be addressed I guess. Thoughts? --Peter P (talk) 16:42, 4 February 2014 (GMT)

Namespaces - Probably a good move.
Commas in titles - The current technology (#arraymap) doesn't actually require use of commas as separators, though it is the most natural character to me, another sequence could be used. How many pages are there with commas in the title? Unless it's more than a handful, I say keep commas as separators and just botch the titles to exclude that character.
Separate template - I see no benefit from this. Instead I suggest vary behaviour by namespace with a #if block. This is not hard, and will prevent having multiple copies of code, which is not a good road to go down. What's needed to move forward with this is a list of the stuff to vary by namespace. Robin (talk) 22:37, 4 February 2014 (GMT)
OK I guess the 'document' issue is pretty much a legacy one-off anyway. So the principal to adopt is that a template can (in general theoretically and in this case practically) be used for pages in more than one namespace; any differences in usage to be noted against template parameters + conditional display code blocks and reflected in separate form design elements. Form differences in this case will be minor too, since the localcopy field is required in both - just treated slightly differently but using separate forms will address the red-link auto-form-use issue which I reckon is a big plus. I doubt the Comma issue is much of an issue at all, especially since pages so listed are likely to be a relatively small sub-set, so we'll stick with commas and see what happens. The template will need another field though - ie a generic description for the subject list. I'll work on all this over the next few days. --Peter P (talk) 07:21, 7 February 2014 (GMT)

Differences between file and document use of this template

  • |localCopy = Only needed for the document: namespace, should link to an item in the file: namespace.

Serious Problem

I've just noticed that editing existing documents doesn't work - it was broken by the rename because the form system is not redirect aware. This would be a trivial fix if Special:ReplaceText were working, but it's not. I may see whether I can press User:MaintenanceBot into service - else we should probably revert back to the old name. Robin (talk) 22:43, 30 May 2014 (IST)

I have grandchildren staying today and tommorow, so limited time. After I will have a good look at why 'Text-Replce' is not working and upgrade to latest releases (There have been 3 x MW Mainenance releases since the system was last u/graded - also there is a more recent SMW release) --Peter P (talk) 06:22, 31 May 2014 (IST)

AORAN change issue

The last template edit (adding template:AORAN) has caused failure of the document type to display. --Peter P (talk) 09:12, 31 August 2015 (IST)

Question comment

Robin I see that the Wikispooks comment is put out of use. I would have liked to use it on two documents of the II, cyberwarfare related. If I put the whole text in the description it becomes a pretty big box (not looking nice) and I think that from a certain size on problems start to appear (refs missing, text is getting displayed two times). Can you think of something that will work smoothly here? This imo would have been the perfect use-case for the Wikispooks comment thing, but please help me out. Text that I planned to leave there is:

The shortage of qualified personnel to dominate the cyber realm has been noted in the last decade.[1] It appears that from the proposal of the II an encompassing recruiting effort is now underway by the British government through programs like the: "Cyber Schools Hub programme", which is meant to get children interested in hacking and related skills for cyberwar.[2][3]

Sunvalley (talk) 23:59, 4 September 2020 (UTC)

I deprecated |comment since I think Template:Rate is superior for a number of reasons:
  • transparency -- rather than "Wikispooks' comment", it belongs to whoever made it.
  • variety -- anyone who wants to chip in a rating can do so, there's no need to give one opinion paricular weight
  • simplicity -- together with the rating comes a number (1-5), which facilitates navigation somewhat
So far, so theory. In practice, ratings are more complex, not working 100% and not yet widely used. However, a fix is probably not so hard, and I still recommend them, for the above reasons. -- Robin (talk) 17:03, 6 September 2020 (UTC)
Hi, thanks for the explanation. Thought about it, text from "|description" is also copied to other places, so there must be a limitation. "Transparency" is the best point, that is indeed a problem with the (Wikispooks) comment. I will integrate the circumstances in the article. CMS/wiki/server wise I do not know a thing, but would it be possible to use this "|comment" feature under a different name, like: "Additional information", to make it possible again to put in other info for circumstances like this? Sunvalley (talk) 23:13, 7 September 2020 (UTC)
I did forget about: "|note=", can be used for additional information without using the text space of the document itself. - As for ratings, takes some while until changes are shown on my page and even longer for showing up on the rated page. The last rating of Ex-CIA man "kill Putin" seems to take even more time than MS Estonia. As far as text in "|summary=" and "|description=" goes, not sure what it is, but it seems I can not get it to both show up on the rated page at the same time. Anyway, not the priority and my initial concern has a solution. -- Sunvalley (talk) 18:16, 9 October 2020 (UTC)

References