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'))).
| Comment | File | Size | Author |
|---|---|---|---|
| service_name_as_service.patch | 2.48 KB | xmarket |
Comments
Comment #1
greenskin commentedThe latest dev release uses the service id instead of the name.