Board Thread:General Discussion/@comment-15636815-20140122132804/@comment-15636815-20140127080345

What little documentation I found regarding  and   led me to believe that   is meant for short strings, such as a word, and   is meant for long strings, such as, well, a line of text. Further digging showed that I had things backward, more or less.

MediaWiki's Extensions:TemplateData page appears to be the primary source of information about specifications for TD. Although this page includes an easy-to-miss link to the API repository, which contains the latest version of the specifications, I previously missed it.

Items of interest:
 * 1) type:   = Any textual value.
 * 2) type:   = Short text field - use for names, labels, and other short-form fields.
 * 3) According to the specifications in the repository, the proper syntax for the particular type mentioned in (2), above, is  . This is the result of a change in the code that happened 2013-11-07, as verified in the changediff. Unfortunately, the documentation on MediaWiki does not yet reflect this change.
 * 4) The repository page also shows two new data types not shown on MediaWiki:   and.

Although the repository defines  and , I understand neither their purposes nor when to use them. Likewise, I lack proper understanding of. From what I can tell, it's identical to, except perhaps that it has a smaller memory requirement. I am unable to determine with any degree of certainty when to use  instead of , or the benefit of doing so, from the available information in the documentation. Anyone else?

Short version of the paragraph immediately preceding: Since  allows for all string inputs, I think we should use it for all string inputs until we have a better understanding of  .

In addition, the information about  and   do not specify whether the user should enter the link brackets. Presumably, this omission indicates that the brackets also should be omitted. I would have preferred that the extension's author included this information to prevent the current confusion.

Great idea to enter "0" when tax is Free! That definitely keeps things simpler. It's always good when we can make the template take care of those annoying details instead of placing that burden on the users.

Thanks for the blog link, too! LOL ... The transcript shows that we decided to use the ISO8601 format, which is 2014-01-27. Hey, that's a perfect segue to my next paragraph! :P

IDEA: The VisualEditor allows templates to embed other templates, That's good, since Template:OfferLoco is just one of many templates we embed. According to the VisualEditor user guide, embedded templates show up in VE as parameters of the main template. Two thoughts:
 * If users can input data into an embedded template just as easily as they into the main template, that will eliminate the need for editors to format the template call.
 * We could instruct editors to enter dates in the YYYY-MM-DD format, OR we could instruct them to enter numbers for "year", "month", and "day" as separate parameters. Then we could define a  object that combines the three components into one "date" parameter.

After all this talk about saving work for the editors, why would I propose removing "date" as one entry and replacing it with three entries? Mostly, it's for the non-native English speakers. It's easier to translate, and therefore to understand, the complete words "year", "month", and "day", than it is to decipher the YYYY-MM-DD code. True, people should be able to figure it out because it's the "date" field. As an individual who knows bits and pieces of a dozen languages, though, I can attest that it's usually easier to understand the meaning of a foreign word than of a foreign abbreviation.

And I think that's enough for tonight. ;)