Template talk:Calendar

From OpenStreetMap Wiki
Jump to: navigation, search

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)

Podcast {{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‎)

Conference this is a conference
Meeting this is a meeting
Mapping party 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 Conference-icon.svg Meeting-icon.svg /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. Flag of United States 22px.png--Nickvet419 05:55, 23 February 2009 (UTC)

Well someone's just added a bunch of mini Austria flags to just some of the events Austria. 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) Austria

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:

Conference 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) Austria
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 This user is member of the wiki team of OSM (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 This user is member of the wiki team of OSM (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 This user is member of the wiki team of OSM (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 This user is member of the wiki team of OSM (Let's talk) 21:46, 24 October 2018 (UTC)