Skip to content

MultipleLocales

Jump to bottom Edit New page
Shawna C Scott edited this page Jul 27, 2014 · 2 revisions

Serving multiple locations, localizing

**Labels:**Phase-Design

One Instance for Multiple Locations

Localization

One Instance for Multiple Locations

Ideas on using one instance of Calagator to serve multiple locations

User

Calagator picks an initial Locale (e.g., Portland, Salem) for the User

  • Optional/later: This might persist between sessions; either add User model including a Locale field, or set a cookie on the user's machine.

User can change or add to the Locale (i.e., can switch from Portland to Salem, can pick both Portland and Salem, can pick All Locales). For instance, there might be a column with a set of check boxes, that appears on each page.

Overview shows events only for the Locale (plus ability to change or add to Locale).

Event list shows events only for the Locale (plus ability to change or add to Locale). Probably also true for Event/Duplicates

Venue list shows Venues only for the Locale (plus ability to change or add to Locale). Probably also true for Venue/Duplicates

Search Results show events only for the Locale (plus ability to change or add to Locale).

Recent Changes shows events and venues only for the Locale (plus ability to change or add to Locale).

Events

Should each event have only one Locale, determined by its location? (If so, then Calagator can determine the locale from the Geocode.) There are at least two issues. One is the event that's likely to be interesting to people in multiple location. See the edge case below. The other is

Edge Cases

Event is of interest to users in several venues. E.g., RecentChangesCamp 2009 and Open Source Bridge are likely interesting to people outside of pdx. Some ways of dealing with this:

  • Event can have multiple Locales. E.g., Event Edit page has checkboxes for all Locales. User can check/uncheck, except that cannot uncheck Locale that's associated with the Event's Venue
  • Don't worry about this; User can always find event by picking All locales, then doing a search. (I dislike this. It presumes too much user knowledge, and makes it too hard to find the event.)

Event Venue is TBD, or otherwise indefinite. See Venues below.

Event has multiple Venues, not all in the same Locale. Solution: create multiple Events, one per Venue.

Venues

Calagator determines the Locale for each Venue. Determination is based on geocoding.

Edge cases

  • User or Source does not provide a Venue
  • User or Source doesn't provide enough information to determine Locale. This can happen by: deliberately not providing information (e.g., some sources do not provide Venue); putting venue information into the wrong fields (e.g., user mistkenly puts Street Address into (one-line) Address field
  • Venue is TBD. Solution: create one TBD Venue per Locale. People have already done this for [(If we are relying on geocode for localization, then the TBD venue should include enough information so that it can be geocoded.)
  • Calagator picks wrong Locale. (For instance, I recall seeing a message saying that Google was mapping Portland's Gerding Theater to Atlanta.)

Sources

  • Each source could have a default Local for events imported form that source (in case the source does not provide a Venue for the Event).

Localization

Ideas on adapting Calagator for different local conditions (language, date/time format)

  • Calagator should display its messages (as opposed to Event or Venue content) in the local language. One possibility: Rails 2.2 Internationalization. See http://guides.rubyonrails.org/2*2*release\_notes.html
  • Calagator should display dates and times in local format. Some ideas: Format is a variable. Administrator picks default; user can change.
  • Date/Time picker should use the local language and date/time format

INITIAL REVIEW NEEDED

Add a custom footer
Clone this wiki locally