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 wince a few days with the user that tests a new parser. — Verdy_p (talk) 22:12, 11 November 2017 (UTC)

What happened to the template?!


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


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