In keys_api 6.x-1.1 (and before) you had an example in README.txt:

/**
 * Implementation of hook_keys_service().
 */
function hook_keys_service() {
  return array(
    'service_name' => array(
      'name' => t('Name'),
      'description' => t('Description of service.')
    )
  );
}



keys_api_get_key($service,$domain)

This suggest, that "service_name" == $service, but your implementation uses the translatable "name" as $service.
This solution can cause abnormal behavior in multilingual environments. For example take a look for my implementation:

/**
 * Implementation of hook_keys_service().
 */
function gmaps_keys_service() {
  return array(
    'gmaps' => array(
      'name' => t('Google Maps API key'),
    )
  );
}

I will translate 'Google Maps API key' to 'Google Térkép API kulcs'. In this case I can add an API key when my current language is english, than I should change my current language to hungarian, than I can add the same key for the hungarian string. I don't think this is the best way to support language based API keys.

This patch implements the suggested behavior and starts using the "service_name" as $service, so you can use keys_get_key(array('service' => 'gmaps')), instead of keys_get_key(array('service' => t('Google Maps API key'))).

CommentFileSizeAuthor
service_name_as_service.patch2.48 KBxmarket

Comments

greenskin’s picture

Status: Needs review » Fixed

The latest dev release uses the service id instead of the name.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.