Description of problem:
This BZ is actually tracking two related problems in detect_locale:

1.) An intermittent error, "undefined method `<=>' for :"fr-FR":Symbol". We should probably make both both the user's requested languages _and_ I18n.available_locales return strings for easier comparison. Currently we cast the user's locales to symbols (to match available_locales), but you apparently cannot sort symbols.

2.) detect_locales currently doesn't do anything intelligent with country-specific locales. If you request "fr-FR" and we have "fr" available, we don't consider it a match since we're just comparing strings for equality. It's unclear to me whether we will ever want to support these country-specific versions (e.g., have an en-US and an en-GB to cover the minor differences, like "color" vs. "colour"). If we want to support them, we should probably be smarter -- if you request en-GB, "en" should suffice. Alternatively, if we *don't* think we will ever have region-specific dialects, we could just strip them off of the incoming languages -- if I request "en-US", just take it as "en".

A third nit is that if _none_ of your languages match (i.e., there is no intersection between my ACCEPT_LANGUAGE settings and what the app has translations for), we end up assigning the locale to nil. It seems like we fall back on the default locale in this case and everything works fine, but it feels like potentially sloppy code. (I wrote it, so I can say that. *grin*)