Take the 2-minute tour ×
Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It's 100% free, no registration required.

We need a way to copy English translations of picklist labels into other languages. Given a picklist on the Opportunity object with values Y and N translated as follows:

Value       EN_us      DE     FR
Y           Yes        Ja     
N           No         Nein     

We want a scheduled apex job to fill in missing labels in French with "Yes" or "No" from the English translation until such time as someone overwrites them manually with "Oui" and "Non".

Why? Because if the label is missing in French then SalesForce displays "Y" and not "Yes". In this example it might still be understandable for an French User that "Y" means Yes but in other examples, with picklists containing technical keys it would not be.

I know how to query the labels in my current language and get "Yes" but how to I query and set labels in a different language? Ideally I want to do this in apex and not by deploying files.

List<Schema.PicklistEntry> vals = Opportunity.SomeField__c.getDescribe().getPicklistValues();
for (Schema.PicklistEntry val: vals) {
    system.debug(val.getValue()+'='+val.getLabel());
    // 1. How can I do val.getLabel('FR') ?
    // 2. How can I do val.setLabel('FR', 'Yes') ?
}

I have tried looking at the .objectTranslation files in the IDE but they are empty even though we have translated values. For example Opportunity-de.objectTranslation contains simply:

<?xml version="1.0" encoding="UTF-8"?>
<CustomObjectTranslation xmlns="http://soap.sforce.com/2006/04/metadata"/>

even though we have several translated picklist labels in German on the Opportunity object.

UPDATE: Using Ant (or Force.com IDE) to retrieve translations always returns empty files even though we have picklists translated.

<sf:bulkRetrieve ... metadataType="CustomObjectTranslation" retrieveTarget="retrieved"/>

returns empty files (e.g. Opportunity-no.objectTranslation):

<?xml version="1.0" encoding="UTF-8"?>
<CustomObjectTranslation xmlns="http://soap.sforce.com/2006/04/metadata"/>

Same story for metadataType="Translations"

share|improve this question
    
How many languages support you need ? –  Mohith Kumar Jan 28 '13 at 12:08
    
We have active users in 17 different languages. Multiply by 20 picklists and it's impractical to translate manually. If SalesForce would only fallback on the English translation we would be saved! –  Marc Jan 29 '13 at 7:28
add comment

1 Answer

Translations sound suspiciously close to Metadata API which means it's not accessible from Apex (at least not without some callout-like hacks). Can't you just use standard Translation Workbench? Export to Excel, let users translate, import back... sure beats crafting XML files.

Besides even if you had such possibility to modify translations from Apex - how do you plan to write a "metadata change sniffer" that'd "fire" every time a new picklist is added or existing one modified? Or that would detect the fact a new language was enabled in the system?

I believe "you're doing it wrong" ;) I think it makes more sense to leverage the fact Salesforce kept picklist name & value identical (so no way to configure system out of the box to have <select>...<option value="Y">Yes</option>...</select>). If you need this Yes/No somewhere else as Y/N - consider making a formula field?


EDIT

Translations metadata missing in Eclipse - check your package.xml. Mine contains (among others)

<types>
    <members>*</members>
    <name>CustomObjectTranslation</name>
</types>
<types>
    <members>*</members>
    <name>Translations</name>
</types>

("Translations" is for apps, custom labels etc) and my Opportunity-es.objectTranslation has correct data in it:

<?xml version="1.0" encoding="UTF-8"?>
<CustomObjectTranslation xmlns="http://soap.sforce.com/2006/04/metadata">
...
<fields>
    <help>Si es Indirecto, debe rellenar el campo de mayorista</help>
    <label>Directo / Indirecto</label>
    <name>Direct_Indirect__c</name>
    <picklistValues>
        <masterLabel>Direct</masterLabel>
        <translation>Directo</translation>
    </picklistValues>
    <picklistValues>
        <masterLabel>Indirect</masterLabel>
        <translation>Indirecto</translation>
    </picklistValues>
</fields>
...
<fields>
    <name>LeadSource</name>
    <picklistValues>
        <masterLabel>Advertisement</masterLabel>
        <translation><!-- Advertisement --></translation>
    </picklistValues>
    <picklistValues>
        <masterLabel>Customer Event</masterLabel>
        <translation><!-- Customer Event --></translation>
    </picklistValues>
...
share|improve this answer
    
I'd welcome alternative solutions to the problem I describe. Our organisation has users in 20 different languages. Multiply that by 20 different picklists and it's easy to see that not every picklist value is going to be translated in every language. For us it is inacceptable to have a user see Y (or a technical code like P702) in a picklist field just because nobody had time to translate it. –  Marc Jan 29 '13 at 7:24
    
If scheduled apex (weekly job checking for untranslated labels) is not an option how would we do it with the metadata API? Every attempt to export translations has resulted in suspiciously empty files. The standard workbench export has to be done manually and is unwieldy. –  Marc Jan 29 '13 at 7:26
    
I'd also like to add that the only reason we are using the translation workbench is because we want hard technical codes (and not fickle texts) in our picklists - for integration purposes. If our picklists contain say product names instead of product codes our integration would be very fragile. If anyone has a good solution or alternative to picklist translations to this I would be interested to know. How best to maintain a readable text AND technical code on objects? Hardcoding the mapping into a separate formula field? :-O –  Marc Jan 29 '13 at 7:31
1  
I've updated the answer if you really want to go the metadata route - shouldn't be too hard to write a parser that extracts commented out original labels and puts them back. But that's really fragile IMHO... For small amount of picklist values - yes, I'd make a formula! For bigger - maybe convert picklist to filtered lookup to helper object? You'd store lang code, Name = translated to French and whatnot and product codes as normal fields. Bit of duplicate data but easy to export & mass modify. Filter the lookup by user's pref. lang for example. –  eyescream Jan 29 '13 at 9:58
    
A generic object ("table" of translated lookup values) filtered by context and language is a novel idea. A bit less user friendly (requires more clicks) but worth considering thanks! Amazing to me that I'm the only one on the web battling with mass-translating picklists... –  Marc Jan 29 '13 at 15:09
show 2 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.