1. The event can then link to information about the calendar. This is an easy way to get quick basic contact information.
2. It is part of the security model--each event must be authenticated somehow. An calendar's password allows the appropriate folks to add/update events for that calendar.
p1 $lang{help_evt_title1} = "Help: Event Title"; $lang{help_evt_title2} = <Events are automatically associated with calendars, so you don't need this information in the event title.
p1 $lang{help_evt_details1} = "Help: Event Details"; $lang{help_evt_details2} = <Email addresses and URLs will automatically be converted to links. In addition, you can also write html in the event details.
If you write html, make sure you properly quote things.
This is wrong:
<a href=www.planscalendar.com>link<a>
This is right:
<a href="www.planscalendar.com">link<a>
The same thing applies to the <img> src attribute
Here's a template you can copy & paste. It has html for nice-looking formatting:
Details Details Details.
<ul>
<li> What
<li> Where
<li> Why
<li> How
<li> Who to contact
</ul>
When you add a recurring event, Plans makes copies of the event for successsive days, weeks, or months, according to the pattern you specify.
Take care when creating a recurring event!
Use the "Preview Dates" link!
If you make a mistake, you must
edit or delete each copy of the event individually.
After adding a recurring event, you can modify or delete the copies individually. You cannot manage them as a group. Once created, they are not tied together in any way.
Basically, recurring events are for speeding up data entry.
p1 $lang{help_recurrence_type1} = "Help: Recurrence type"; $lang{help_recurrence_type2} = <If this is selected, the event will occur only once a month, on the same day (or range of days). Most of the events that follow this kind of pattern are holidays.
Most meetings follow this type of pattern. Events can be scheduled to occur on every week of the month, or on certain weeks.
Once Again, use the "Preview Dates" button!
Note--Some events occur on more than one week of every month (the first and third week, for instance). This type of pattern cannot be selected, but can be created by adding the event twice--once for the first week and once for third week, for the above example.
Note--Some events occur other or every third week of the year. This type of recurring event is not supported.
p1 $lang{help_fit_into_year1} = "Help: Fit event into year"; $lang{help_fit_into_year2} = <If this is selected, the event will repeat each month.
Here you can choose which months the event will occur in. This is useful for events that stop for a period (like during the summer).
If the calendar is for an organization with a homepage, this provides a 1-click connection between the event and the homepage.
p1 $lang{help_cal_details1} = "Help: Calendar details"; $lang{help_cal_details2} = <email addresses and URLs will automatically be converted to links.
Here is a handy template you can copy & paste. It has html for nice-looking formatting:
General Description
<ul>
<li> Contact information
<li> Meeting Time
<li> Meeting Location
</ul>
Oh yes.
The calendar password should be easy to remember and easy to tell to others. Not much need for passwords like "Dxk&2+15^N" or "p\$\$9EM}L". We're not talking about national security here--just enough to keep out the rifraff.
When entering a password for the first time or changing it, you are asked to type it twice. This guards against typos (if you make a typo when entering a new password, it's tough to fix).
p1 $lang{help_current_cal_password1} = "Help: Current calendar password"; $lang{help_current_cal_password2} = <Hold the Ctrl key while clicking to toggle the calendars on/off individually.
p1 $lang{help_cal_selectable_calendars1} = "Help: Background (merged) calendars"; $lang{help_cal_selectable_calendars2} = <Sometimes, you might want to let the user select from just a few (or none) of the calendars hosted by an installation of plans.
Note that when you add a new calendar, it is not automatically added to other calendars' drop-down lists. This must be done manually.
Hold the Ctrl key while clicking to toggle the calendars on/off individually.
p1 $lang{help_remote_background_calendars1} = "Help: Remote merged calendars"; $lang{help_remote_background_calendars2} = <This is a bit more tricky than merging calendars hosted by the same installation of Plans as this server. Whenever your calendar is displayed, Plans makes a http request to the remote server, and fetches its calendar data.
To merge a remote calendar, you'll need to know the address (URL) of that calendar. Plans will send a request to that calendar site, asking it what calendars are available for remote merging (the remote site's calendar owners can disallow this).
If all goes well, you'll get a list of calendars to choose from. Check the boxes by the ones you want to merge, and click "Merge Selected Calendars".
When you update your calendar, the remote calendars will be added.
In summary, it's a three-step process:
(1) Click "Add remote calendars", and find the remote calendars (using the URL)
(2) Select the ones you want, and click the "Merge" link
(3) Update your calendar. Don't forget this step!
Note: If you have too many remote merged calendars, you may notice slower performance from your calendar.
p1 $lang{help_cal_background_events_display_style1} = "Help: Background events display style"; $lang{help_cal_background_events_display_style2} = <
Normal--In this style, background events will look just like events for the selected calendar.
Single color--All background events will show up with this color (white or grey are popular choices). This can help if you have a great many background events.
Faded--This is just fanciness for fanciness' sake :) Background events will have their colors faded by the percent you choose. If the colors are light to begin with, they'll appear white.
p1 $lang{help_cal_list_background_calendars_together1} = "Help: List background calendars together"; $lang{help_cal_list_background_calendars_together2} = <| ATL | EST | CST | MST | PST | ALA | HAW |
| -4 | -5 | -6 | -7 | 8 | -9 | -10 |
Right now, this setting doesn't do much, since all events in Plans are all-day events. But when plans does support specific times, this setting will matter.
p1 $lang{help_cal_date_format1} = "Help: Date format"; $lang{help_cal_date_format2} = <It must contain "mm", "dd", and "yy", in any order, separated by "/" characters.
p1 $lang{help_cal_week_start_day1} = "Help: Week start day"; $lang{help_cal_week_start_day2} = <If preloading is turned off, calendar pages are around 60K. If preloading is on, calendar pages are 80K or more. (But event details appear instantly when events are clicked). For users with faster network speeds, preloading gives a better experience.
If you have many users with slow connections, you may want to turn off preloading (uncheck the box). Likewise if your calendar is extremely busy (preloading dozens of events each month can bloat the page size past 200K)
p1 # added in version 5.4.5 $lang{help_cal_new_calendars_automatically_selectable1} = "Help: Make new calendars automatically selectable"; $lang{help_cal_new_calendars_automatically_selectable2} = <This is done using an http request. It can add additional bandwidth and processing load to your server, but not much.
It's useful if you're (for example) a school, and you would like outside websites (sports leagues, community programs, youth groups) to be able to display your events on their calendars.
p1 # added in version 5.5.6 $lang{help_remote_calendar_requests_password1} = "Help: Require a password"; $lang{help_remote_calendar_requests_password2} = <Note that this does not apply to normal calendar viewing. People can still look at your calendars with their web browser. They just can't make requests to get the raw data.
This is only useful if a really popular calendar happens to remotely include yours, and your server bogs down as a result. Until this happens, it is reccommended you don't require a password (it just adds hassle.)
Actually, the password isn't really the best solution for the above problem. The best solution would be to block the offending server's IP address. But if you don't have that type of control over your own server, the password may help.
p1 $lang{help_cal_popup_window_size1} = "Help: Popup window size"; $lang{help_cal_popup_window_size2} = <Units are pixels, default is 400x400.
p1 $lang{help_cal_custom_stylesheet1} = "Help: Custom stylesheet"; $lang{help_cal_custom_stylesheet2} = <This lets you customize the calendar's fonts, colors and backgrounds.
This .css file must be publicly accessuble through the internet (in other words, you should be able to access it by pointing your browser at an URL).
A good place to start is with a copy of this calendar's default css file:
p1 $lang{help_cal_custom_template1} = "Help: Custom template"; $lang{help_cal_custom_template2} = <The template file gives you greater control over the layout and structure of the calendar page.
A template file is just an html file with some ###special tags### that plans recognizes.
Your custom template file must be publicly accessuble through the internet (in other words, you should be able to access it file by pointing your browser at an URL).
A good place to start is with a copy of this calendar's default tempate file:
If you make a typo in the template address, plans will simply use its default template and print a warning at the very bottom of the calendar.
p1 $lang{help_recurring_event_change_all1} = "Help: Apply changes to all events in a series"; $lang{help_recurring_event_change_all2} = <The dates of the events in the series will not change. These are computed when the series is first created. Individual events in the series can be deleted or have their dates changed. But the only things you can do to an entire series are change the details or delete the series.
p1