Template talk:Calendar

Dividing next two and next six months

What is the separation in "within the next two weeks" and "in less than 6 weeks" good for? Dates already are in chronological order.

And the calendar template should be as language neutral as possible, as it is included in many (localized) main pages.

IMO: It makes no sense and the heading isn't language-neutral or multi-lingual. => Get rid of it.

-- /al 07:17, 24 June 2015 (UTC)

I don't like that division either. It's already a lot of work to keep the calendar up to date (IMHO). To move events between the sections adds even more work. --holgermappt (talk) 18:54, 25 June 2015 (UTC)

Yeah this is a disaster for the simple job of removing past events & moving them on. It makes the whole task of updating the calendar for even organisers much harder, much easier to break the template. Please get rid of it! SK53 (talk) 20:35, 22 July 2015 (UTC)

Deprecate "speaking"

Shouldn't we deprecate {{Cal|speaking}}? Or what is this good for?

/al 12:01, 5 November 2014 (UTC)

New icons

New categories added /al 12:22, 5 November 2014 (UTC)

	{{Cal|podcast}}	for radio/podcast recordings
MISC	{{Cal|misc}}	for anything else

May I suggest new icons: (update: already implemented /al 12:06, 7. Mai 2014‎)

	this is a conference
	this is a meeting
	this is a mapping party

not touching the beer!

/al 10:42, 3 April 2014 (UTC)

Nice icons. :) I could imagine them in the calendar. Perhaps release them as PD to make clear that changing the link target to some place that doesn't provide attribution is legal? --Tordanik 19:10, 3 April 2014 (UTC)

Added the source and noted the "©2000" there. So we probably can't use them. :( Maybe somebody could make something similar? /al 06:52, 4 April 2014 (UTC)

Just to mention: I got icons from a friend that are free to use /al May 2014

<noinclude> tag

Instructions on how to edit (table format) this calendar template, I've moved onto the template page itself. This is possible using the nifty <noinclude> template feature. Everything within this tag, does not get included on the including pages, i.e. you dont see those intructions appearing on the Main Page. This feature is also used on wikipedia to document how a template should be used/edited. -- Harry Wood 14:02, 12 December 2006 (UTC)

I think that revisions such as this one:

 14:07, 4 September 2007 Harry Wood (Talk | contribs) (Make a distiction (bold) between bigger mapping parties and piddly little ones)

are potentially a bad idea. This resulted in the ShoHo mapping party being made bold and font size +1, but the Ljubljana mapping party being called 'piddly' and being demoted. The Ljubljana mapping party was arguably more significant than ShoHo as it was the first mapping party in Slovenia, whereas the ShoHo was just another mapping party in London. If London was significant because of its completeness, surely Mikel's talk at Brighton Bar Camp was equally significant due to Brighton's completeness?

If there is a valid reason for a mapping party being bold, it needs to be explained in the comments section, otherwise we will see rapid inflation in mapping party boldness and size.

--Nick 08:44, 10 September 2007 (BST)

Mini Flags

What do you think about adding Mini Flags to this calendar to help illustrate the country the event is held in? ex. --Nickvet419 05:55, 23 February 2009 (UTC)

Well someone's just added a bunch of mini Austria flags to just some of the events . As this is right now, it looks very inconsistent, giving undue prominence to these Wiener Stammtisch events. Might look OK with all the flags filled in I suppose. Or it might just look like more clutter. -- Harry Wood 18:11, 30 August 2012 (BST)

I added in all of them. Looks good to me. --Nighto 18:32, 30 August 2012 (BST)

As you liked my SmallFlag idea, couldn't we now just omit the ", [[Country]]" on every entry, now? It would make the calendar much more readable, especially on the Main_Page (and the width of the calendar column could be reduced). /al 08:00, 9 March 2013 (CET)

Agreed. It also reduces the English text on multilingual main pages. --Andrew (talk) 12:02, 9 March 2013 (UTC)

+1 --holgermappt (talk) 22:38, 9 March 2013 (UTC)

hCalendar microformats

I've been asked to look at the possiblity of applying hCalendar microformats to this template.

What do you think of the including a machine-readable date like this:

Mar 2-5

FOSSGIS 2010, Osnabrück, Germany

(2010-03-02-2010-03-05)

? Pigsonthewing 18:18, 4 March 2010 (UTC)

I don't see why we shouldn't have it. Go ahead! :-) --Nighto 17:54, 21 September 2012 (BST)

Microformats don't need to be displayed just to be there. You can use class="value-title" to put data into the title. But we should design an event template that receives all the parameters needed for an event item. /al 08:10, 9 March 2013 (CET)

We have a problem here because the date is abbreviated and there's no parameter in the Dm template to support the required year. And note that we don't want to display dates in their long ISO forms: they are abbreviated. The long ISO dates would need to be in hidden (CSS style="display:none"), while we display localised dates in abbreviated form (not necessarily in English and not even necessarily the Latin script): this table was initially meant to be rendered in a compact form on the home page of this wiki: it is a minimal summary, not a ful ldescription of the event (that's why we require putting a relevant link in the description column).

Also since the begining, event are presented as a set of separate column elements. So this would require changing the format to use a single template for the whole event row, so that we can insert the extra (invisible) attributes. Doing that in the existing format would make the table difficult to edit.

Finally it's difficult to separate the event name from the location name: we just expect to have at end of the description an optional place name just before a country name, and then some small flags/icons (from right to left, the first one being for the country). In most cases the event is partially geolocalized, and it's already hard to convince contributors to geolocate their future events precisely.

So we would first need to design a new template generating a row (the first "|-" line for the row header plus the next line containing cells). However this will break existing external parsers that process this table but with enough flexibility on the optional parameters, and without creating something to complex to edit. Experience shows that most events are added just once, not very long before they occur but with very minimal info: the info is in fact given elsewhere in the referenced article or external link placed at the begining of the description (this is usually an wiki/HTML page, but can be also an image/PDF, or social network page from which we cannot easily parse the content as it is dynamic or has many other unrelated infos).

I see no easy way to do that without breaking exising uses and creating new difficulties for contributors (that should not have to be afraid of the syntaxic requirements).

See the next comment below about the existing parser which could emit such microformats on its result page (it will have to infer the year for dates). — Verdy_p ^(talk) 11:03, 16 July 2017 (UTC)

I tried this implementation. This uses the most recent microformats2 specification (using short prefixes rather than legacy generic terms in class names) for "h-events".

But this requires changing a bit the format (notably for dates: this requires setting the year).

For now the description is entirely in a "p-name" property; I've not separated properties for the event location which usually occurs at end of the description text (but sometimes in its leading title); all I did was to isolate the description from the small flags at end of the description, using a new span.

I had problems locating an unclosed span in the first try, causing incorrect formatting at end of the table. This is fixed now.

I updated the doc. I hope this does not break the existing parser described in the next comment. But may be this will in fact help it parsing the content more efficiently. — Verdy_p ^(talk) 19:09, 16 July 2017 (UTC)

Calendar parser for WeeklyOSM and Wochennotiz

The calendar is parsed automatic for the weekly published Wochennotiz and WeeklyOSM.

This was previously done by OSMBC.

You can support the team by controlling your entry in the public preview. -- TheFive 00:45, 13 March 2016 (UTC)

Microformats is a good initiative and has amny supporters, it will allow other parsers to work without necessarily freezing this wiki to an old state and presentation.

WikilyOSM and Wochennotiz are not the only candidates for such modifications which will allow many more feeds to be used (including RSS).

This was tested on multiple existing generic microformats parsers (not made specifically for this wiki) and there's an example given, returning calendars in JSON format (other formats are possible as it uses approved common practices used on many websites: XML, HTML, iCal, .ics...). — Verdy_p ^(talk) 12:14, 20 July 2017 (UTC)

This is done by osmcalendar (made by Thomas Barris). -- TheFive 00:45, 11 November 2017 (UTC)

The end of support of the previous OSMBC parser been puyblicly announced by its past author. The link to the public preview is still not affected by this change of maintenance. — Verdy_p ^(talk) 18:20, 11 November 2017 (UTC)

Don't know where Verdy_P has the information from, that the public preview is not supporting the change of maintenance. As Owner of the published link i knew where the info comes from. You can use it to check against the new parser. TheFive (talk) 20:35, 11 November 2017 (UTC)

WeeklyOSM published that info itself last week (note! I'm not speaking about the preview but about the previous undocumtned/broken parser you changed above by mixing dates)! Also I'm in direct contact since a few days with the user that tests a new parser. — Verdy_p ^(talk) 22:12, 11 November 2017 (UTC)

I'd like to have acess to the source code (read-only) or a running test version of the parser to know how it parses the entries and see which ones need to be fixed. I see recurrent problems about the way it attempts to geolocate the events published in WeeklyOSM and this is not corrected after publication. Basically, it expects locations to be indicated at end only as "city name,n country name", but various events need to specify this more exactly, due to homonymies, so we should be able to use "city name, region/district name, state name, country name", or even "POI name, city name, region/district name, state name, country name" in a comma-separated list (with variable number of items). The parser should try to parse the list from the end, going backward to see if it can locate the most major entity name written before it and if it can, then look for the previous name. This would then allow putting the most precise place name in the first column, and the country name in the last one of the Weekly OSM calendar, and with links or hints showing additional disambiguating precisions.

Ideally I'd like also to optionally specify how to set a precise geolocation (coordinates) that the parser could use directly instead of guessing (it is most probably using Nominatim searches to guess the place by geocoding, but sometimes the locations guessed by the current parser gives completely incorrect results).

Is that possible to use some "{{Geo|lat|lon}}" template (with parameters in decimal degrees) or similar that the parser would recognize ?

Or so that the template will generate directly the suitable microformat ,which (when found) will avoid using the "guesser" completely (by just processing the generated HTML, instead of parsing the wikicode).

It would also give more freedom about how to summarize the event description displayed in this wiki home page. If the external parser processes the HTML with microformats instead of wikicode, we could avoid the strict HTML+wikitable syntax and generate each row with a simpler template allowing more easily editable details and allowing different presentations (a compact one just for the wiki home page, a more complete presentation elsewhere). Also events would be published without being necesarily geolocated (notably worldwide online events whose place is actually a website or service, or chat, or survey, or forum place, or online video events, or some pages on social networks). We could also more precvisely tag the language and allow translating each event description (instead of displaying them only in English or in a single local language suitable for the geolocated place).

Using a template could also allow providing a short description (for the home page) and a longer one (displayed elsewhere, or possibly in a popup served by some custom Javascript that a site admin could provide and would be also useful for lots of pages where we want to have details hidden by default but easy unhidden by a single click or mouse hovering, similar to the popups for POIs on uMap). That tempalte would also allow "iCal" or RSS formats to be more precisely tagged and more easily integrated in other sites (which could choose themselves the levelk of details they want, and could also choose their presentation and styling). — Verdy_p ^(talk) 21:05, 2 July 2018 (UTC)

Sorry, I have just read the first paragraph because I have more important things to do than to read your essays but the source code can be found at https://github.com/ThomasBarris/osmcalendar --Nakaner (talk) 23:19, 2 July 2018 (UTC)

It's not an "essay", I expose several arguments because we still lack some freedom of composition of event descriptions, and have dioffictulty to predict how they'll be geolocated.

And it's extremely difficult to remove some of these barriers in something that is not manageable here. — Verdy_p ^(talk) 09:02, 3 July 2018 (UTC)

note: you comment " the mf2py lib returns the end date +1...for whatever reason.." this is not for unjustified reason but because of the microformat specifications. As dates of events are given for 24 hours (there's no time given), the events are set to start at 00:00 and end at 24:00. The microformats allows for times even if we still don't define them in this wiki (but it would be possible to specify it explicitly)! — Verdy_p ^(talk) 09:13, 3 July 2018 (UTC)

What happened to the template?!

Before:

|-
| {{cal|social}} || {{dm|Aug 19|Aug 20}} || [https://www.froscon.de/ FrOSCon with OSGeo & OSM Track], [[Sankt Augustin]], [[Germany]] {{SmallFlag|Germany}}

After:

|-class="h-event"
| {{Cal|social}} || {{Dm|y=2017|Aug 19|Aug 20}} || <span class="p-name">[https://www.froscon.de/ FrOSCon with OSGeo & OSM Track], [[Sankt Augustin]], [[Germany]]</span> {{SmallFlag|Germany}}

The wiki markup has became unreadable, with some mysterious class names and HTML tags. How is that better for dozens of people who edit the page? Visually it is the same.

I propose reverting this change. --Zverik (talk) 11:40, 15 August 2017 (UTC)

This has been documented and dicusssed before. The changes were very minimal to support microformats (the explicit addition of the year was needed to allow infering correct date values, because Dm only specified the month/day but could not infer the year).

This is then only a single span. Unfortunately this template has used explicit wikitable row and cells instead of a single formatting template, and it's not easy to change that (the proposal for using a foratting Event template was attempted and rejected for now, even if it would have improved the maintenance).

What is this cost? a few bytes, always the same, easy to copy-paste from one event to the next one to create.

You come late: this support of microformats was requested since very long (more 4 years ago, see above) and never opposed. It was implemented voluntarily with the minimum options that don't require complexity, globally all looks the same and is very similar. Microformats are not meant to be read only by human visitors of this wiki but read by machines. It is a common practice of calendars on the web to be easily sharable and microformats are the best known practices: lot of sites use this convention, this allows sharing the events across sites (just like many sites propose RSS feeds). — Verdy_p ^(talk) 16:14, 15 August 2017 (UTC)

Could you give me a link to the discussion please? I could not find it. Also, can all this be simplified using a template for a table row? --Zverik (talk) 17:19, 15 August 2017 (UTC)

The talk example you want is just above since 4 years (but this was talked multiple times in various places, it was desired multiple times but still not implemented, even if the needed changes for them was extremely minimalist).

And no, this simplification with an event template for each row was not working with other existing uses of this page that can only parse a table (this could have been done but with more people complaining as it would have been much more radical). For changing it, it would have required more work and discussions to know where there are used. The wya it is does not change the layout and is globally compatible with existing external parsers: there's always been some variation in the HTML presentation of the main column, it was progressively normalized but the initial format sicne the begining as not changed even if we are now a bit more restrictive.

You're the only one that do not understand that the single span introduced does not complicate things, and that refuses to add the year precision in the date field (even if this is explained, and if that does not complicate things at all: copy-paste an existing rown just change the date and the event name and links, adapt the small flags at end where needed: this has always been done like this and does not require more work than before. — Verdy_p ^(talk) 09:41, 17 August 2017 (UTC)

You have a track record of making things gratuitously complicated without providing a simple interface, even ripping out the ones other people create, and you push back against everyone who complains about you. For instance, here, you added a y= parameter to {{Dm}} even though the template was specifically documented as accepting anything valid in Mediawiki with a link to the full specification including years as part of the date. This discourages people from using the wiki and instead they find other places to converse.--Andrew (talk) 16:56, 17 August 2017 (UTC)

For what it's worth, I also feel that the added span and classes are potentially problematic. We expect this table to be edited by anyone who wants to host an event, which includes people who are unfamiliar with the wiki, and may have never seen HTML code before. Sure, copying an existing line still works. But messing with some strange codes that you don't really understand still takes some confidence. I've seen people shy away from simpler tasks because of a fear of breaking things.

I actually like having microformats used more in OSM, but I wonder if we can't find a better solution. Wrapping this into a template, for example, seems almost ideal from a usability point of view. And as there aren't all that many parsers out there (is there even one besides the Weekly OSM one?), updating them should be a possibility. After delaying this change for years, we should be able to spare a month or two to wait for the parser implementation to be updated. --Tordanik 17:04, 17 August 2017 (UTC)

The parameter is there only to apply the same year to both dates, yes it could be added in the two dates but the way the Dm template works makes it difficult to infer a valid date from a partial date, as it is internally parsed as being the current year (so it does not work with history, and requries an override). For now it is made for compatibility, but not all historic pages have been converted to use an explicit year. So without it, it cannot emit a valid microformat (the year is completely unparsable and there's no way to see if one is really indicated).

I did not want to complicate things and really tried with the minimum needed to support these long-awaited and multiple times requested event microformats (so no it was not a "gratuitous" change). No one had attempted to propose a way to implement it. I did not break any functionality the way it was made.

It would have been preferable to have a base template for each event, but an earlier attempt to do it was canceled because it broke external parsers used by other sites (that were trying to parse the wiki code directly). Anyway this was discussed with several site maintainers. — Verdy_p ^(talk) 17:49, 17 August 2017 (UTC)

Add Lat/Lon to be able to show events on a map

Currently it is not possible to show the events on a map because there's any information about lat/lon and geolocation doesn't really works because of the insufficient location. At the OSM Hackweekend in Karlsruhe i've created a new Template Template:LatLongMF2 which generates a hidden (non-visible to human readers on the page) h-geo microformat which can be parsed by microformat parsers. For a proof of concept i've copied a few events to User:Haribo/Calendar and have written a script which parse it and show it on http://usergroups.openstreetmap.de (Layer: Events). Please have a look at it and if nobody has any objections i would make it public to the Calendar Template - Haribo (talk) 14:02, 21 October 2018 (UTC)

Thanks for this addition, but to me it looks like you would have to add the coordinates into the template, right? This seems to be a bit complicated given that many people edit this template (there is already a discussion about the difficulties of the template above). Why can your page not infer the locations from the given data and store it there? --Tigerfell  (Let's talk) 18:23, 21 October 2018 (UTC)

Yes, if you would like that an event is shown on a map, then you have to add the coordinates via the new LatLongMF2 Template. I've read the discussion about the difficulties above. Therefore i've created this small easy to handle and capsulated template, and it was important for me, that i wouldn't break anything. Certainly, I would prefer it if the calendar template would be fundamentally revised. Which page do you mean? usergroups.openstreetmap.org or User:Haribo/Calendar? And which given data do you mean? As i mentioned above, the current information about the location is really insufficient. - Haribo (talk) 18:57, 21 October 2018 (UTC)

I was thinking of querying a geocoder with the given data from the template and saving the results internally at usergr....de. By given data I refer to the data that the users have already entered into the calender (postal addresses, dates of meetings,...). I am concerned that the calender template will be less usable and the users do not really care about the coordinates, so your template will be used by some users only. --Tigerfell  (Let's talk) 19:26, 21 October 2018 (UTC)

I don't know any geocoder that can work with "dates of meetings". And

<big>'''[[State of the Map Asia 2018]]'''</big>, [[Bangalore]], [[India]]

isn't really a (full) "postal address". For that i need several clicks through the hyperlinks to find out, at which exact location this event takes place. - Haribo (talk) 05:56, 22 October 2018 (UTC)

I was thinking of querying "Bangalore, India" and then place the marker at the city node. Again, do you really think that the users will add the coordinates? --Tigerfell  (Let's talk) 09:27, 22 October 2018 (UTC)

@Haribo: I did not want to stop you. I just wanted to know whether you took this into consideration. If you disagree with me it is fine, please go ahead. --Tigerfell  (Let's talk) 21:46, 24 October 2018 (UTC)

Streamlining templates

This template has a high barrier to entry for OpenStreetMap event organizers who aren't intimately familiar with wikitext. The detailed documentation helps to a degree, but adding an event still requires sifting through and copy-pasting cryptic syntax. I drafted a template that outputs an entire row for the calendar, so that contributors only have to know about this one template and its parameters and don't have to know about wikitext table syntax or microformats. The new template has TemplateData, which means if we were to move the actual event editing to a new page in the main namespace, like Current events, then people could fill out a form in VisualEditor to add an event without writing any code at all.

According to the documentation, the WeeklyOSM blog now parses the microformats in this template's generated HTML, so restructuring the underlying wikitext source code should have no effect on WeeklyOSM. Are there any other significant consumers of this template that still parse wikitext? If not, I can replace this template's contents with invocations of Template:Calendar/event and update the documentation.

Eventually, we could have Template:Calendar transclude a JSON file (still editable as a wiki page, but with automatic syntax highlighting) via the Scribunto extension, if contributors find JSON more comfortable to edit than template syntax or the VisualEditor form. Then software like iD could fetch the events as JSON without having to parse microformats. But one step at a time. I'd welcome feedback about Template:Calendar/event – are there any missing options that you think you'll need for an event?

 – Minh Nguyễn ^💬 17:13, 13 April 2019 (UTC)

Have you asked anyone at WeeklyOSM what they actually want? This seems a generally good idea and the documentation could of course be cleaned up. There is an argument that we should go in with a power saw and only keep what we know we need --Andrew (talk) 20:30, 13 April 2019 (UTC)

@Wynndale: That's a good idea. Nakaner or others on the Wochennotiz/WeeklyOSM team, what do you like or dislike about the current template's output? Do you think the proposed changes will create any problems for OSMBC? What would you keep in a more radical overhaul of the system? – Minh Nguyễn ^💬 23:56, 13 April 2019 (UTC)

From the POV of the person who maintained this calendar during the last months, I would appreciate a solution which would allow us archive the past events automatically. I thought about w:mw:Extension:Cargo because you could use a form to add new events and have a database for archiving. This would avoid messing with Wikitexts once and for all and also allow the Finish users to update their calendar which mainly features events in Finland (currently outdated/unmaintained). Additionally, I could stop moving upcoming events out of the <noinclude> section. I have not checked the compliance with microformats though, but it emits JSON via the API.

@Minh Nguyen: How does archiving work in your setup? --Tigerfell  (Let's talk) 21:08, 13 April 2019 (UTC)

@Tigerfell: First of all, thank you for taking the time to keep the calendar tidy. So far, I've taken a conservative approach of only improving the editing experience, as a first step, since quite a few local events never make it onto the calendar. That could cause an increase in events, which naturally leads to your question about filtering and archiving. Locale-specific calendars can be implemented in a couple ways: for example, {{Calendar/event}} could hide or show output based on the page it's on, or {{Calendar}} could send the whole table through a Lua module that strips out other countries' entries. Archiving is something a bot typically does on Wikimedia sites. I think it'll be more straightforward to write an archiving bot for the calendar once {{Calendar/event}} is in place, because the entries will be more uniform with less effort.

I haven't looked into Cargo before. It sounds interesting, but it makes me wonder if there's something similar that relies on data items. Anyways, if this low-hanging fruit works out, it'll open the door to further changes.

 – Minh Nguyễn ^💬 23:56, 13 April 2019 (UTC)

Cargo uses a relational database. I am not sure if Wikibase is the right way to go, because this is completely unrelated to any tags. In addition, it is pretty strictly structured already. I would really appreciate some sort of input form and this querying mechanism (I would prefer querying to using a bot).

I guess @Yurik: can help us. Would you suggest using Wikibase?

If yes, is there any advantage in using Wikibase for this? How can we create forms, so that the users will know that a calendar entry ensembles of a location, a type, a starting date and so on? How can we avoid that users mix tags and events when storing all of them in Wikibase like someone adding highway=primary is of type Conference? --Tigerfell  (Let's talk) 22:31, 14 April 2019 (UTC)

@Tigerfell:, @Minh Nguyen:, @Wynndale:: Data items are not really tied to key or tags. Just like in OSM you can have a geometry and attach any types of key/values to it, in a data item you can have any kind of properties (keys) with any types of values (much more flexibility than just a string like in OSM, e.g. multiple values, value type, qualifiers, validators, etc). This means that we can easily create data items for the calendar events, e.g. instance-of = calendar-item; event-time = ...; event-language = ...; event-location = ...; etc etc etc. The sky is the limit. Querying is actually far easier with this, because we have Sophox which has all that data. A query like this would get you all of the events in a given time range (and we could obviously filter it further by event type, locale, ...). The values inside the <...> will be the actual properties we will create for this type of data.

SELECT * FROM {
  ?id osmdt:<instance-of> osmd:<calendar-item>.
  ?id osmdt:<event-time> ?time.
  FILTER (?time > ... && ?time < ...)
}

Also, it will be relatively easy to make an infobox that shows the data about a single event. The only complexity will come from showing many events at once, because wiki markup does not support querying. But there is a very well known workaround (wikidata uses it all the time) -- there is a bot that run a query, and updates a wiki page with the query's output, while also converting it to a pretty text according to some rules. See Listeria bot - we would just have to point the bot to run on OSM wiki + Sophox. The other relative difficulty is a more convenient user interface to add new events - e.g. a javascript, possibly running as part of the wiki itself (i.e. Gadget), or as a standalone app that uses oAuth, that automates the creation of new calendar items. If we want to improve this process, we would have to develop this entry form regardless of the storage medium we use - a wiki page or a data item. --Yurik (talk) 02:39, 15 April 2019 (UTC)

P.S. Here's Wikipedia docs on using Listeria bot. And we will need to set up this bot regardless - it will allow us to maintain lists of tags on pages as well. --Yurik (talk) 02:54, 15 April 2019 (UTC)

Would newly added events not appear until the next time the bot runs? --Andrew (talk) 19:21, 15 April 2019 (UTC)

@Wynndale: no, the list won't update until then, but the bot can easily check the "recent changes" api, and update the list accordingly. I already do that with the key/tag pages - my bot checks RC feed every minute and updates the data items. --Yurik (talk) 19:28, 15 April 2019 (UTC)

@Minh Nguyen: Please feel free to change it (from my POV). I just wanted to drop some ideas, but since we apparently need a bot for that, I would probably employ one when I will find the time. My calendar is currently filled up with this "Deletion policy" debate, but if you want to ask something, just ping or use my talk page. --Tigerfell  (Let's talk) 09:28, 17 April 2019 (UTC)

I agree that the calendar is not a good example of usability for end users contributing events. If you want to change anything, please check if our code is still able to parse it or file a pull request. We parse the microformat because Verdy_p insisted on changing the calendar two years ago, not because we like microformats.

I myself (and a few others in the German OSM community) think that no further work except usual day-to-day business should be invested into the calendar on the wiki. Although MediaWiki can do nearly anything except running a Linux kernel, a calendar on the wiki is a ugly hack and just an example that MediaWiki can do nearly anything but nothing with a good user experience. It would be better, to build a stand alone calendar web application where people authenticate with their OSM account via OAuth and add/edit events. Such a tool can archive old events automatically, provide exports in various formats and follows the Unix principle that a tool should do only thing and that well. It is likely that if such a tool is ready at any point in the future, WeeklyOSM will switch to it without any announcement (and copy over all existing events). --Nakaner (talk) 08:16, 17 April 2019 (UTC)

Thank you, it's good to know that WeeklyOSM is open to an off-wiki approach. For the time being, I'll try to get Template:Calendar/event in good enough shape to start using, since most of the work has been done already and it will improve usability somewhat. The only remaining task is to revamp {{SmallFlag}}, because automatically guessing a flag file name based on a place name can easily lead to mistakes (think "Georgia"). After that, either a standalone OAuth-consuming application or something based on data items would be a great next step. We'd finally have a viable way to integrate the full calendar with osm-community-index. If anyone is interested in taking on that project, I'd be happy to help with any necessary on-wiki integration. – Minh Nguyễn ^💬 04:59, 19 April 2019 (UTC)

While it's absolutely true that usability would benefit from better tools, we shouldn't forgo the low-hanging fruit in the hope that the perfect solution is going to be available any day now. So I agree with adopting the /event template – it's a clear improvement, and doesn't stop us from switching to something better.

I've played around with it a bit, and it seems to work well! I would, however, make the region optional: Many current calendar entries do not specify a region, and while adding a state or other region to place names is common in some parts of the world, it's highly unusual in others.

In theory, I would also like the country text to be optional (as per the discussion several years ago), as well as the city ("Mycity mapper meetup, Mycity" is rather redundant). However, I understand that this would break the WeeklyOSM parser and should therefore be avoided. --Tordanik 17:07, 24 April 2019 (UTC)

I also see the template as sensible in the short term, and would add that any other solution should let events (especially the ones organised at shorter notice) be publicised before the next week and should not fracture event publicity into two rival calendars.--Andrew (talk) 06:13, 25 April 2019 (UTC)

@Tordanik: |city = and |region = are both completely optional, but currently the parameters you specify determine which flags you see. So German events could specify just |city = and |country =, as they do now, and there would be no region flag. On the other hand, U.S. events should normally specify |city = (since most states are vast), but most city flags are obscure and would be superfluous. Moreover, many European events currently have to specify a coat of arms image as an override for a city flag, making it more difficult to contribute.

What if we never show city and region flags and only show country flags? That would make it much more manageable. (Actually, I kind of would prefer to combine all the place-related parameters into a single |location =, but that would probably force us to abandon the flags entirely.)

 – Minh Nguyễn ^💬 00:26, 26 April 2019 (UTC)

@Minh Nguyen:: It seems that leaving the parameter blank does indeed work. Omitting it entirely produces broken syntax for the flag image, though.

Showing only country flags wouldn't be a problem for me; I can't speak for anyone else, though. I do think there's value in having the location structured somewhat, as it keeps the door open for future automated linking of events (e.g. from a city's wiki page, or even the city's detail view on osm.org). --Tordanik 15:43, 27 April 2019 (UTC)

@Tordanik: Thanks, fixed. – Minh Nguyễn ^💬 22:33, 27 April 2019 (UTC)

@Minh Nguyen: When do we switch to the new calendar? --Tigerfell  (Let's talk) 19:30, 5 May 2019 (UTC)

@Tigerfell: I finally got around to solving the flag issue by removing most of the flags. :^D I took the liberty of also cleaning up {{Calendar}} visually. Now the country flags go in a separate column, and the dates are aligned. The OSMBC calendar parser turned out to be a source of frustration, because it screen-scrapes this template in a very rigid manner. I did what I could to avoid breaking weeklyOSM. I've migrated {{Calendar}} over to {{Calendar/event}} and updated all the instructions. I didn't migrate {{PastEvents}}; not sure whether it's worth the effort. If the addition of a new column is a problem, we could maintain two separate past tables for now. – Minh Nguyễn ^💬 01:12, 13 June 2019 (UTC)

I didn't originally set out to improve the template's performance, but migrating to {{Calendar/event}} sped it up by 27%:

−

NewPP limit report Cached time: 20190613005627 Cache expiry: 86400 Dynamic content: false CPU time usage: 4.533 seconds Real time usage: 13.335 seconds Preprocessor visited node count: 97759/1000000 Preprocessor generated node count: 48459/1000000 Post‐expand include size: 239227/2097152 bytes Template argument size: 28143/2097152 bytes Highest expansion depth: 16/40 Expensive parser function count: 3/500 Unstrip recursion depth: 0/20 Unstrip post‐expand size: 187/5000000 bytes Lua time usage: 2.250/15.000 seconds Lua virtual size: 16.46 MB/50 MB Lua estimated memory usage: 0 bytes Transclusion expansion time report (%,ms,calls,template) 100.00% 5340.679 1 -total 60.90% 3252.462 135 Template:Dm 58.92% 3146.881 138 Template:LangSwitch 57.23% 3056.681 1261 Template:Langcode 33.99% 1815.364 215 Template:SmallFlag 29.15% 1556.619 430 Template:Dir 1.34% 71.776 1 Template:Edit 1.13% 60.381 152 Template:Cal 1.05% 56.022 1 Template:Documentation 0.59% 31.584 1 Template:Calendar/doc

+

NewPP limit report Cached time: 20190613005350 Cache expiry: 86400 Dynamic content: false CPU time usage: 3.299 seconds Real time usage: 5.307 seconds Preprocessor visited node count: 78175/1000000 Preprocessor generated node count: 49109/1000000 Post‐expand include size: 301537/2097152 bytes Template argument size: 46142/2097152 bytes Highest expansion depth: 17/40 Expensive parser function count: 253/500 Unstrip recursion depth: 0/20 Unstrip post‐expand size: 187/5000000 bytes Lua time usage: 2.010/15.000 seconds Lua virtual size: 17.41 MB/50 MB Lua estimated memory usage: 0 bytes Transclusion expansion time report (%,ms,calls,template) 100.00% 4768.343 1 -total 96.40% 4596.640 140 Template:Calendar/event 73.87% 3522.360 140 Template:Dm 71.14% 3391.963 143 Template:LangSwitch 45.58% 2173.607 861 Template:Langcode 13.27% 632.837 140 Template:Flags 1.49% 70.951 1 Template:Edit 1.48% 70.695 1 Template:Documentation 1.45% 68.979 157 Template:Cal 0.74% 35.476 1 Template:Calendar/doc

 – Minh Nguyễn ^💬 01:21, 13 June 2019 (UTC)

I do not think migrating past events is worth the effort. It also did not happen when the previous old formats were changed as you can see from Past Events 2007. I moved the events in the old format to Past events 2019. Glad to hear that performance increased, but the use of expensive parser function seems to be pretty high. This would not have worked last year i.e. before Yuri requested the sysadmins to increase the limit. However, the figure is within the limit, so no need to worry yet ;-). --Tigerfell  (Let's talk) 22:22, 13 June 2019 (UTC)

Yeah, {{Calendar/event}} automatically links |name =, |city =, |region =, and |country = to matching wiki pages if they exist. #ifexist: is one of the expensive parser functions. Come to think of it, is it that important to link every occurrence of "Germany" or "England" if there's already a link to the specific event? We could significantly cut down on resource usage and make the calendar look tidier by delinking the second or third link in each row.

I'm also trying to optimize the Main Page in other ways, like replacing {{Dm}} with a more efficient (and more intelligible) {{Event date}} and possibly rewriting {{Languages}} later on.

 – Minh Nguyễn ^💬 23:21, 13 June 2019 (UTC)

I do not think you need to link to the country. The flag icon already links to it anyway.

Wynnedale tried to optimize {{Languages}} in August/September 2018 and it did not work out. I would currently not recommend changing {{Languages}}, in case we switch to suffix notation for languages (which I would appreciate). --Tigerfell  (Let's talk) 07:42, 17 June 2019 (UTC)

I'm making some good progress in Module:Languages and Template:Languages/sandbox. The actual list of languages needs to be refined, and there are a number of edge cases in the existing templates that need to be accounted for, but I'm quite optimistic that we can dramatically improve performance while keeping the functionality that people care about. – Minh Nguyễn ^💬 05:25, 18 June 2019 (UTC)

How much would it speed things up if we change the categories that were created for some languages with capitalised language prefixes? --Andrew (talk) 07:35, 18 June 2019 (UTC)

@Wynndale: I'm not sure about the existing template system. For Module:Languages, it wouldn't make a big difference in speed, but anything we can do to make spelling conventions more consistent on the wiki will simplify the code. For example, there was a special case in the existing templates about an "EN:" prefix, so I moved all the existing ones, eliminating the need for special cases in the module. I also eliminated usage of the deprecated option to specify the namespace separately from the base page name. Let's discuss further improvements in Template talk:Languages. – Minh Nguyễn ^💬 15:47, 18 June 2019 (UTC)

@Minh Nguyen: We have currently an issue with the number of expensive parser functions. Template:PastEvents has already 527 (limit is 500) and it just includes five and a half months. I suggest removing the country links for now. --Tigerfell  (Let's talk) 06:55, 28 November 2019 (UTC)

@Tigerfell: Done. – Minh Nguyễn ^💬 10:08, 28 November 2019 (UTC)

Thanks. Unfortunately, the expensive parser function count did not drop as much as I had hoped. There are currently four calls to {{#ifexist: }} for linking the flag icon, the wiki page, the city, and the region. While it is save to assume that there exists a wiki page for every country, this does not hold for region and city pages. Either we de-link them too or we add a parameter so the users decide whether to link to them. The second approach is similar to the old calendar format. --Tigerfell  (Let's talk) 08:47, 30 November 2019 (UTC)

Missing entries

According to this preview, the "#geomob London" and "OpenStreetMap Foundation public board meeting" entries are missing for some reason. It may be due to the lack of a country on the OSMF board meeting's entry. – Minh Nguyễn ^💬 18:13, 16 June 2019 (UTC)

The end dates for most events are wrong as well. CC @SunCobalt: --Tigerfell  (Let's talk) 07:34, 20 June 2019 (UTC)

@Tigerfell: Thanks for the heads-up. This change fixes the issue, though the #geomob and OSMF board meeting items are still missing. – Minh Nguyễn ^💬 16:02, 20 June 2019 (UTC)

Automating archives

Tigerfell, SK53, and others have been helping to manually archive old events for some time – thanks for the effort you've put into keeping the calendar tidy. But archiving is something that software is really good at, so we should look for ways to automate the process. The more obvious solution would be a bot could parse {{Calendar}} and automatically move entries over to Past Events. But that requires someone to run the bot continuously; a pure wiki-based approach would be preferable. We brainstormed about some of these solutions above; now that {{Calendar/event}} has been deployed, we can sketch out these ideas in more detail.

I thought about storing all the events in a page with the content model set to JSON, which {{Calendar}} would format and include. When editing a JSON page, MediaWiki enables a source code editor with instant syntax checking and highlighting. (Try editing this page for instance.) JSON would be easy to parse, and the syntax editor would help users avoid syntax errors. However, the extra punctuation means it isn't necessarily easier to edit, and having every event on the same page means we'd still have to archive events manually or using a bot.

So instead of putting every event on a single page, I think we should have separate pages for each day on which an event might fall, such as Current events/2024/11/23, that contain nothing but {{Calendar/event}} transclusions in ordinary wikitext. {{Calendar}} would automatically compile a list of the next month and a half of events. (A Lua module would iterate over the upcoming dates and transclude each existing daily page.) We can use an input box with a preloaded template and edit intro to help users create these daily pages:

Enter start date:

Current events would have one of these input boxes for each valid event type.

Since each day would have its own page, we'd no longer need to maintain an archive manually. Instead, we'd point people to Special:PrefixIndex/Current events/2019/ for all the events in 2019.

What do folks think of this approach?

 – Minh Nguyễn ^💬 00:48, 1 July 2019 (UTC)

How would multi-day events be entered? --Andrew (talk) 07:41, 1 July 2019 (UTC)

I guess we could stick them in the page for the start day, though it does mean a Module:Calendar would need to look backwards by a couple weeks to catch any ongoing events. {{Calendar/event}} could insert hidden delimiters that the module could split on, to make sure it includes only the ongoing event and not any single-day event that happened to begin on the same day. – Minh Nguyễn ^💬 08:03, 1 July 2019 (UTC)

It's not automated archiving which is an issue. It's a dramatically changed workflow which caught me completely unawares and made me worried as to where the historical event entries had gone for 2019. The calendar page must be regularly edited by around 100 or so contributors, for some of whom these may be their only wiki edits. Unfortunately when a change is made, however well-intentioned, it can be very confusing for someone who is not following all the changes in how the wiki is managed. So instead of taking 30 seconds to add the old entries to the past event page I spent 15 minutes trying to find where the 2019 events had gone. I would suggest such changes be prominently flagged in some way (e.g., OSM diary entry, guest post to OSM Weekly, personal message to regular contributors to a page) where it will be more obvious to casual wiki users. SK53 (talk) 14:01, 1 July 2019 (UTC)

Out of curiosity, were you archiving events from Current events or adding already-passed events to Past Events? I did admittedly overlook Past Events and neglected to follow up after Tigerfell updated it to the new layout (which I appreciate). For what it’s worth, I belatedly announced the workflow change in a diary post yesterday. Any future change will definitely be communicated more broadly, because it’ll have an impact on more than just the editing experience. But hopefully also we can make manual archiving a thing of the past. – Minh Nguyễn ^💬 16:28, 1 July 2019 (UTC)

Well, could work. I would prefer having one page like Past Events displaying all past events of that year, so you have an overview of them and not just a list of pages with events. That should be possible using some transclusion mechanism. --Tigerfell  (Let's talk) 08:31, 2 July 2019 (UTC)

Yes, we could even make it so that generating a monthly archive would take two clicks: one that preloads a page that transcludes all the daily archives, and another that saves the page. – Minh Nguyễn ^💬 18:16, 2 July 2019 (UTC)

@Minh Nguyen: I do not think we need monthly reports. An annual report is sufficient to answer questions like "How often did we meet last year?" or "When was the spring meeting or did we cancel it?". --Tigerfell  (Let's talk) 08:26, 9 July 2019 (UTC)

I think any report that relies on template transclusion would have to be monthly rather than yearly, because of MediaWiki's transclusion limits. After a certain number of transclusions on a page, MediaWiki gives up and just shows a link to the template, no better than Special:PrefixIndex. – Minh Nguyễn ^💬 16:22, 9 July 2019 (UTC)

Doesn't it depend on the size of the template? Beijing Bus transcludes {{BrowseRelation}} (redirecting to {{Relation}} linking to Module:Element) more than 1000 times. I mean these pages are probably rather small, right? There is also a tracking category for them, if you want to check the cases where the template include limit was hit Category:Pages where template include size is exceeded. In case of Cs:Trasy KČT which hits the limit the same template was included 3680 times.

All four events of 11 July have a post-expand include size of 6464 bytes. Multiplying this by 366, we end up with about 2.3 MiB which is above the line for 1464 events. However, there were only 499 events in 2018 (≈ 787 KiB), 644 in 2017 (≈ 1016 KiB), and 625 in 2016 (≈ 986 KiB). --Tigerfell  (Let's talk) 09:07, 11 July 2019 (UTC)

Yes, you're right, my mistake. Based on your analysis, there's little risk of exceeding that limit. – Minh Nguyễn ^💬 07:07, 12 July 2019 (UTC)

@Minh Nguyen: Okay, but in general this way looks suitable! We might want to display the events of yesterday in the calendar as well, because I guess that the system would otherwise remove events that might not have past yet due to time zone differences which in turn effect the date. --Tigerfell  (Let's talk) 10:33, 16 July 2019 (UTC)

Given that I'm not among the people who are putting in the manual archiving work at the moment, I'm not really in a position to argue. Still, are we sure we want multiple separate mechanisms (Wikibase, JSON) for storing structured data on this wiki, each with their own workflow and user frontend? --Tordanik 15:51, 5 August 2019 (UTC)

Sorry @Tordanik:, I missed your answer because I constantly checked below my text. It does not really matter for me. I guess that using Wikibase would have the advantage of displaying local events only (like on the Finish main page). However, someone would need to set up Wikibase and a template and stay in touch wiki Weeklyosm so we do no break their calendar. A comparable approach of using Wikibase for Taglists was discussed in the beginning of August as well, but no progress surfaced yet. --Tigerfell  (Let's talk) 09:36, 25 August 2019 (UTC)

@Minh Nguyen: Anything I can do to push the calendar towards automation? --Tigerfell  (Let's talk) 21:27, 1 August 2019 (UTC)

Hi, is there a way to add a recurring event or do you need to go in and add them all individually?

Hi Martijn, I believe there's no way to add a recurring event except manually. --Tordanik 19:48, 11 June 2020 (UTC)

OSMCal

As of last week, this template now relies on OSMCal, which has better facilities for archiving and subscriptions. Thanks to Thomersch for your hard work on this functionality, the OSMF for the microgrant that facilitated the migration, and a special thanks to Tigerfell and others for your unsung work over the years to keep the wiki-based calendar functional and tidy despite the many technical limitations. – Minh Nguyễn ^💬 18:21, 21 December 2020 (UTC)

That is very kind. You are welcome. You did some enhancements as well. Thank you for that! --Tigerfell  (Let's talk) 15:47, 22 December 2020 (UTC)

A string to translate

Where does the string "Add your event to OpenStreetMap Calendar" come from? From an external source? Would it be possible to make it translatable? maro21 21:54, 20 April 2021 (UTC)

It originates from OSMCal MediaWiki extension. You can translate the string via editing the source code at https://github.com/thomersch/OSMCALWikiWidget/tree/main/i18n. Two points to note:

1. The language setting is derived from the language setting of the page, not the language prefix of the page name or the user's language setting.
2. Updates to the source code might be deployed at the next update of MediaWiki. This is the standard procedure of OWG. It might take a while... --Tigerfell  (Let's talk) 11:58, 21 April 2021 (UTC)

Translation on “Add your event to OpenStreetMap Calender”

Something I noticed while looking at other pages was that they all had the add your event text to be in English. I suggest adding a section on creating a pull request to translate the text. The reason why I’m saying this was because it was very hard for me to find out that the text was based in a github repo and not on a translated template. Broiledpeas (talk) 17:14, 27 June 2024 (UTC)