Looking through the Spring 13 release notes (pg 121) I would expect the new fields to have "Code" appended. E.g. Account.ShippingCountry becomes Account.ShippingCountryCode.
This lines up with the online docs for Account:
ShippingCountryCode (beta)
Type
picklist
Properties
Create, Filter, Group, Nillable, Sort, Update
Description
The ISO country code for the account’s shipping address.
Is your connection to the API or Apex class metadata using api version v28.0?
See also:
OK, we figured it out by trial and error, didn't see it documented anywhere.
There are some standard picklists that are shared by multiple objects: "Lead Source", "Account Source", and "Industry".
For example, "Lead Source" field is on Contact, CampaignMember, Lead, Opportunity, and Account. Although on Account it's named differently ("Account Source"), the picklist values are shared by all of these objects. To deploy this picklist, we need to make sure that we only list it on one of these objects, and comment it out from the others, otherwise we get a build error.
Currently our build is set up as follows:
1) "Lead Source" field is deployed via "Account Source" field on the Account object, from where the picklist values are copied by Salesforce automatically to four other objects.
2) Industry field is deployed via Account object. It is commented out on the Lead object. From Account, SF automatically makes these picklist values available on the Lead.
3) The Lead's name field is actually a composition of several other fields including the "Salutation" picklist (Miss, Mr., etc.). Bizarrely to deploy that you need to deploy the CampaignMember.Salutation field
Best Answer
In the Metadata API CustomFieldTranslation has a picklistValues field of type
PicklistValueTranslation[]
. It has a masterLabel and translation string.So your package.xml for the retrieve call would be something like:
You will get something like:
You can get the translated picklist values directly in Apex without having to go via the Metadata API.