Difference between revisions of "Template talk:Document"

From Wikispooks
Jump to navigation Jump to search
(question update)
 
(31 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)
+
=== Description ===
  
: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)
+
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)
  
::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)
+
=== Production date ===
  
:::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)
+
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)
  
== SMW properties problem ==
+
=== SeeAlso ===
  
Robin - have a look at [[Special:Properties]]
+
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)
  
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)
+
== Date Format Standardisation ==
  
== DocProv use of the 'RED' Broken template is broken on Iframe pages ==
+
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)
  
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)
+
== Form lagging a bit ==
  
== Publication date fails ==
+
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)
  
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)
+
=== Comma separated lists ===
  
== Author - conditional statement ==
+
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)
  
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)
+
== Dates issue following recent Forms upgrade to v2.6.1 ==
  
== Author notes ==
+
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)
  
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)
+
== Reinstatement of FileProv ==
  
:: 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 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)
  
== AORAN + Subject ==
+
===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}}.''
  
Good stuff Robin. Makes for a much better set of DocType properties.
+
== Serious Problem ==
  
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)
+
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 List ==
+
: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)
  
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
+
==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)
  
# Standardising doctypes
+
==Question comment==
# Fixing "source" which combines 2 bits of info. Maybe add |SourceURL and use |Source as a name
+
[[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:
# 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)
+
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> 
  
== ToDo + General ==
+
[[User:Sunvalley|Sunvalley]] ([[User talk:Sunvalley|talk]]) 23:59, 4 September 2020 (UTC)
  
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)
+
: I deprecated {{t|{{!}}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. -- [[User:Robin|Robin]] ([[User talk:Robin|talk]]) 17:03, 6 September 2020 (UTC)
  
== Date issues ==
+
:: 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)
  
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)
+
::: 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)
  
: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:
+
==References==
#I think I favor the 3 parameter solution unless SMW is proved effective at dealing with missing dates/months
+
{{reflist}}
#Providing missing data items is always good - some of the Document:s are randomly missing sources and/or dates
 
#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)
 

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