Template
@Sir Joseph, Howcheng, and Dweller: This is a follow-up thread to the original thread at BotReq. Example use. 12 Jewish holidays are populated. -- GreenC 19:14, 24 August 2018 (UTC)
Design notes
- Hebrew Calendar localfiles are not evenly covered up to 2100 because the hebcal.com API is not returning consistent data for some of them beyond a certain point. This appears to be a problem with their API which may be fixed in the future when they can be filled in.
-- GreenC 13:55, 27 August 2018 (UTC)
json vs Lua module discussion from IAN
Seems to me like that page should be a Module page, stored in a Lua table, since it's not hooking into a Javascript system but instead the Module. --Izno (talk) 15:59, 30 August 2018 (UTC)
- That's probably what will happen but I used JSON for proof of concept, I like doing things 3 times over again :) Although honestly there is no major performance issue with mw.text.jsonDecode() vs. mw.loadData(), the JSON file will be more accessible to more users than Lua code would be, and JSON is now a universal format. If all your doing is storing configuration data that will be accessible to the largest number of users. -- GreenC 17:23, 30 August 2018 (UTC)
- I assumed there wasn't a significant performance delta--my point was more that if you're handling data consumed by a Module, you should probably default to providing that data as a Module (a Lua table), unless there are other circumstances of interest (particularly, that the data to be consumed will be consumed by more than just a Lua module). I suppose if the template becomes widely used, it's going to end up template protected either way. (I didn't realize that JSON could be edited by anyone?) Lua does provide a better access point I think into the MediaWiki library, so constructs like your
datasource
probably would not be needed, or not needed in the same way (since e.g. I'm pretty sure Lua can manipulate the time display directly, so you don't need to provide the time parserfunction in the JSON, just the final format). --Izno (talk) 21:58, 30 August 2018 (UTC)- Date calculators are handled as third-party plugins which users can add or change as they are developed. There are too many varieties and difficulties to build a general purpose moveable date calculator. For example, just to calculate Easter there is Module:Easter a significantly complex affair. Something similar is needed for Hanukah but doesn't yet exists, so it uses a local data file with dates listed up to 2050. If Wikidata can provide Hanukah data it will be able to pull it from there also. Then there are 100s of 1000s of other moveable dates to tackle, some easy to calculate, some hard, some impossible without data files. Anyway, the template doesn't need to be modified with each case as the calculators are self-contained in
datasource
. -- GreenC 23:17, 30 August 2018 (UTC)- I guess my concern is that you don't really have static data in your JSON file then and so you shouldn't be storing it as if you do. Does jsonDecode accept data that might change? --Izno (talk) 23:24, 30 August 2018 (UTC)
- Notice the "YYYY" in the calculators. This gets replaced with the target year
|year=
. The text indatasource
is not live only an instruction for what the template should execute (preprocess) during runtime. Anyway I'm probably ditching JSON entirely in the latest revision, there are a couple advantages to going native Lua table. -- GreenC 00:06, 31 August 2018 (UTC)
- Notice the "YYYY" in the calculators. This gets replaced with the target year
- I guess my concern is that you don't really have static data in your JSON file then and so you shouldn't be storing it as if you do. Does jsonDecode accept data that might change? --Izno (talk) 23:24, 30 August 2018 (UTC)
- Date calculators are handled as third-party plugins which users can add or change as they are developed. There are too many varieties and difficulties to build a general purpose moveable date calculator. For example, just to calculate Easter there is Module:Easter a significantly complex affair. Something similar is needed for Hanukah but doesn't yet exists, so it uses a local data file with dates listed up to 2050. If Wikidata can provide Hanukah data it will be able to pull it from there also. Then there are 100s of 1000s of other moveable dates to tackle, some easy to calculate, some hard, some impossible without data files. Anyway, the template doesn't need to be modified with each case as the calculators are self-contained in
- GreenC, there is one important performance difference: a lua data module is only loaded once when parsing a page, while the json code will be loaded and parsed for each template transclusion in the page being parsed. Just so you know. —TheDJ (talk • contribs) 08:01, 31 August 2018 (UTC)
- TheDJ Thanks. Yes I read last night there was some magic with mw.loadData() and started converting to Lua. This is the third time I've converted the data so hoping it will be final! -- GreenC 11:50, 31 August 2018 (UTC)
- I assumed there wasn't a significant performance delta--my point was more that if you're handling data consumed by a Module, you should probably default to providing that data as a Module (a Lua table), unless there are other circumstances of interest (particularly, that the data to be consumed will be consumed by more than just a Lua module). I suppose if the template becomes widely used, it's going to end up template protected either way. (I didn't realize that JSON could be edited by anyone?) Lua does provide a better access point I think into the MediaWiki library, so constructs like your
Wikidata
There was a discussion on Wikidata (Aug, 25-29 2018) about integration with this template, and long story short to produce moveable dates, in most cases, requires running a query and Lua can't do it. Example query for Hanukkah. -- GreenC 21:23, 31 August 2018 (UTC)
Data cite
@Pppery: - The citation information should not be removed from the Events Module.[1] The template can be used in non-mainspace pages etc.. the citation information is there for whoever wants to use it for whatever purpose, including in non-mainspace. It is an optional command argument, if you don't want it in your mainspace page then don't use the |cite=
argument. There is no reason to delete it from the Module itself.
Also, self-referential is not entirely clear, it's courtesy information so readers understand the dates are being calculated and where to find the calculator, should they wish to verify the dates. Our primary objective is Verification, a core pillar and policy of Wikipedia, WP:SELFREF is a weaker MOS Guideline and should not trump our primary goal of Verifiability. Also it is a courtesy to notify before making major changes, particularly a change based on Guideline vs Policy. And you should be using a Sandbox instead of editing on the fly and causing breakages. -- GreenC 17:31, 17 February 2019 (UTC)
- There are a grand total of eight pages outside of mainspace that use this template. Four of them are part of the documentation of the template itself. That leaves only four pages, rendering any argument of "this can be used outside of mainspace" moot. Likewise, including a link to the module does not provide a verifiability benefit: Module:Easter and Template:Calendar date have no references no references, and Template:Hebrew year does not reference a generalized method of converting dates into the Hebrew calendar. Even if there were references on those pages, it would be better to cite them directly rather than force readers looking for citations into a editor-oriented template or module documentation page. And this issue transcends individual articles: a link to a editor-facing template or module is no more acceptable on one article than another, hence not specifying
|cite=
in some articles is not a solution. {{3x|p}}ery (talk) 19:07, 17 February 2019 (UTC)