[07:31:50] An alternative could be to have the input of type Z20420; since it has a reading function, you should be able to use it in Wikipedia (and the reading function already handles a lot of formats) (re @Dnshitobu: Regarding this, I think this code runs well on python but does not run on Wikifunctions [07:31:50] def Z24876(Z24876K1): [07:31:51] import re [07:31:53] ...) [08:24:33] I tried to implement it on Z24880. I haven't connected the implementation yet so you can check if it's ok (re @dvd_ccc27919: An alternative could be to have the input of type Z20420; since it has a reading function, you should be able to use it in Wikip...) [12:02:15] @dvd_ccc27919 thank you for updating it but I think the challenge with the current function is that, it only works for one date format which is DD/MM/YYYY but there are other date formats that current do not work yet like [12:02:15] *MDY (Month, day, year) [12:02:17] *DMY (Day, month, year) [12:02:18] *YMD (Year, Month, Day) [12:02:20] *JUL (yy/ddd) [12:02:21] *ISO (YYYY-MM-DD) [12:02:23] *USA (MM/DD/YYYY) [12:02:24] *EUR (DD. MM. YYYY) [12:02:26] *JIS (YYYY-MM-DD) [12:02:27] My question is, do we have to create separate functions to handle all of these or we could loop through a nested if statement to accommodate these difference, if you can help, please go ahead and implement it in code lets test it. [12:19:27] Now I've tried to connect the implementation for Z24880, so you can test it. It requires as input an object of type Gregorian calendar date (Z24880), so the function itself doesn't need to do the parsing (re @Dnshitobu: @dvd_ccc27919 thank you for updating it but I think the challenge with the current function is that, it only works for one date ...) [12:24:13] If you call that function from Wikipedia, the parsing is done by the reader of Gregorian calendar date (Z20808), which already handles a lot of formats. Most importantly, it can be customized to specifically handle the most used formats in Dagbani (re @dvd_ccc27919: Now I've tried to connect the implementation for Z24880, so you can test it. It requires as input [12:24:13] an object of type Gregorian ca...) [12:59:31] perfect! Thank you but it still displays the results with quotes [13:01:16] Those quotes are not real. They're only in the Wikifunction UI to signal the fact that it is a string (re @Dnshitobu: perfect! Thank you but it still displays the results with quotes) [13:02:17] https://www.wikifunctions.org/wiki/User:Dv103/Sandbox [13:02:18] Here there are two examples on how it actually displays on wikitext [13:48:32] @Dnshitobu which date formats are used in Dagbani? Because it seems to me that they are functionally indistinguishable from the English ones. Do you think it makes sense to use Z23984 as the parser function also for Dagbani dates? [14:23:37] the format is mdy (re @dvd_ccc27919: @Dnshitobu which date formats are used in Dagbani? Because it seems to me that they are functionally indistinguishable from the ...) [14:26:18] So does Z23990 work? Or are there some conventions different from the American English ones? (For example: how do you write the epoch?) (re @Dnshitobu: the format is mdy) [14:41:02] yes this works [14:52:45] How do you write the epoch (Before Christ/BCE vs. Anno Domini/CE)? (re @Dnshitobu: yes this works) [14:56:34] Now I've made Z23990 the reading function also for Dagbani (re @Dnshitobu: yes this works) [15:04:19] we usually capture the [15:04:20] BCE as pɔi anabi Yisa dɔɣam [15:04:21] CE as ti zaamani [15:04:23] AD as Anabi Yisa kpibu nyaaga [15:08:33] Do you think the reader function should be able to parse also those expressions? (re @Dnshitobu: we usually capture the [15:08:33] BCE as pɔi anabi Yisa dɔɣam [15:08:35] CE as ti zaamani [15:08:36] AD as Anabi Yisa kpibu nyaaga) [15:13:09] Absolutely, that will be great [15:19:13] We mostly in our home for cultural practices such as festivals, seasons etc reference the lunar calender, that is the Hijra calender and it is affectionately called the Dagbang goli. You can read more about the dates structure from this document [15:19:14] https://docs.google.com/document/d/1u7-ZeY7NHt75JICUPAYky3-7KgkvauD_W3fBjmvpFO0/edit?tab=t.0#heading=h.gf6hp9o3gi0j [15:31:22] I've implemented those (re @Dnshitobu: we usually capture the [15:31:23] BCE as pɔi anabi Yisa dɔɣam [15:31:24] CE as ti zaamani [15:31:26] AD as Anabi Yisa kpibu nyaaga) [15:32:30] Perhaps it should be better to create a different reading function that can handle all those formats (re @Dnshitobu: We mostly in our home for cultural practices such as festivals, seasons etc reference the lunar calender, that is the Hijra cale...) [15:33:54] And btw, I think it should be nice in the future to have a type representing the Hijra calendar [18:37:49] I think if it follows the same pattern, we could create it right away (re @dvd_ccc27919: And btw, I think it should be nice in the future to have a type representing the Hijra calendar) [20:32:55] For now type creation is still allowed only to the devs, so it's still a slow process (re @Dnshitobu: I think if it follows the same pattern, we could create it right away)