Regionalisation/Geolocation best practices

[Uncle Cheese]

Hey, all,

We're in the process of adding regionalisation and geolocation features to silverstripe.org as part of our new presence in the UK. I'd like to gather some thoughts on how you might approach this at a technical level. I have a lot of ideas, but I'm keen to find out how others are doing it. Here are the basic requirements:

Regionalisation

• ss.co.uk redirects to ss.org/uk/
  
• ss.co.au redirects to ss.org/au/
  
• etc.. We could scale this out to several regions.
  

Once a region is established, the user qualifies for region-specific content -- for instance, homepage content, "contact us" content, and special blog entries that are tagged with that region (though most will still remain global)

Geolocation

For content that already exists in a variety of countries, the region defined by the URL doesn't matter so much, and we'd like to show the most relevant content based on geographical proximity.

• Developer network listings float the closest members to the top. This is geopolitical agnostic. If I'm in Slovenia, Innovatif probably comes first, but if I'm in Paris, I would see listings in London before I see listings in Marseilles.
• Same for showcases
• Meetups are filtered by those that are near to you
  

Things I'm curious about:

• Thoughts on the cost of GeoIP lookups, and caching the result. Do we just download an entire GeoIP database (4GB)  and do the lookups locally?
• Where do we draw the line between what the client is responsible for and what will be handled server side? JavaScript is really good at geolocation, and there are many libraries available. How realistic is it, given a small data set ( < 1000 rows ) to ship the whole lot to the client and calculate all this stuff client side? (We consider HTML5 geolocation a UX hazard, so we imagine the user's lat/long would be determined server-side and stuffed into a global browser variable)
• URL/domain handling: How do we ensure URLs are cachable, which is to say that a single URL doesn't serve up different content based on a user's location? How do we deal with the issue of routing against a base URL that doesn't really map to anything in the site tree? (/uk/blog)
• Anything else you can think of? Real world experience with this issue, etc..
  

Thanks heaps, guys!

[Marcus Nyeholt]

Have you looked at what the personalisation module offers around the region-specific content? That _may_ be helpful in some cases. 

For geolocation we've used solr's geo distance sorting combined with general search. It may be more nuanced with european cases, as they may speak a completely different language across a nearby border and not be a relevant result; but I'm not sure if this is an issue or not. 

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

[Hamish Friedlander]

How much are you looking to develop new code for this?

I've had a desired API for 3.2 (I guess maybe 4.0 now) for a while which I've been calling state. Basically, Versioned, Subsites, Translatable and (to some extent) Regionalisation are all subsets of "the whole lump of pages" based on some portion of the HTTP request that may or may not be the URL path.

uk.silverstripe.com and /or silverstripe.co.uk

silverstripe.com/uk/

silverstripe.com?region=uk

silverstripe.com (with region=UK in the session)

I've been imagining a core API that handles all these by being able to map portions of the request to various states, and then calculate a canonical URL (which could either then redirect or set a meta-canonical) and appropriate DataList query filters, etc.

So in this case, all those options would set "region" to "UK". You could then decide to redirect to silverstripe.com/uk or whatever you prefer.

This has all been designed so far to deal with selecting between whole page subsets of all pages, not with personlisation-style sub-page content sections (like when you're just replacing a particular area with region-specific options). I think it would still extend to that sort of usage, but haven't thought it though completely.

Hamish Friedlander | CTO
SilverStripe

Hamish Friedlander | CTO
SilverStripe
http://www.silverstripe.com/

Phone 

+64 4 978 7330 Extension 51

Skype

hamish.friedlander

Physical

SilverStripe
Level 1, Lowndes Associates Building
18 Shortland Street

Auckland 1010, New Zealand

Post

PO Box 3098
Shortland Street

Auckland 1140, New Zealand

--

[Uncle Cheese]

That sounds like exactly what we're looking for at a low level. Ingo and I talked a lot about using this as an opportunity to improve routing in the framework, so perhaps we should make this a bigger project and look more at the state API you're describing. The biggest issue I can see right now, other than blowing up the scope, is that it would put .org in the awkward position of running on a fork of the framework until 4.0 is released.