We've been working on a project that requires CiviCRM to respect Drupal's internationalization/localization settings (set by i18n and l10n modules). Here is how I made that work using Drupal 4.7 / CiviCRM 1.4.

1. Config change
To handle this as a special case for CiviCRM (and thus transparent, backwards compatible, etc.), use the CIVICRM_LC_MESSAGES constant (set in in civicrm.config.php) to pass the value 'i18n'.

2. Changes to modules/civicrm/CRM/Core/Config.php

i. Force in the Drupal i18n/l10n values: add check for CIVICRM_LC_MESSAGES=='i18n' and set lcMessages as follows:
- determine the languages supported by CiviCRM (subdirs of /l10n/)
- get the Drupal i18n language setting and match any supported language codes
- get the Drupal l10n location setting and match any supported language codes
- default to 'en_US'

ii. Fix internal urls: because CiviCRM composes its own urls, discarding the Drupal i18n setting, force it in by appending it to CIVICRM_UF_BASEURL when composing userFrameworkBaseURL.

Notes:
I assume that a match on language is more important than a match on location. (If 'fr_CA' is not available, 'fr_FR' is a better match than 'en_CA'.) The case ( drupal.i18n==civicrm.i18n && drupal.l10n!=civicrm.l10n ) returns the first drupal.i18n==civicrm.i18n case.

English (irritatingly) is a special case of this because en_US is not handled via /l10n/. Thus, ( drupal.i18n=='en' && drupal.l10n!=civicrm.l10n ) must be hacked in to explicitly return 'en_US'.

The Config.php diff is attached below.

[UPDATE]
Improved code/stuff here.