The project I am working on supports many languages and Case record types.

There is also a large amount of dependency between the Case record type and the Case type field (but it isn't one-to-one and there are other variables).

So, we have a trigger which includes like this:

newCase.recordTypeId  = Schema.SObjectType.Case.RecordTypeInfosByName.get(newCase.Type).RecordTypeId; 

However, if/when newCase.Type has been localized, we get a null pointer exception.

So, we need to reverse translation before we can do this.

More, it CAN happen that on a bulk job, the current User is inserting or updating records for users of multiple languages (so we can't "simply" map toLabel against the picklist schema).

We'd rather not hard code a map for reverse translations, nor need to convert our translation files into another set of data to be imported for custom settings.

Does SFDC offer any functionality which could allow us to "untranslate", or that failing, to dynamically create a map from multiple supported languages?

  • 1
    Maybe @zachelrath's badass answer will help you? salesforce.stackexchange.com/questions/11968/… If he ends up with a list of DeveloperName => Id it'd be more reliable for you as Case.Type will be always in org's master language...
    – eyescream
    May 13, 2014 at 13:33
  • @eyescream, The situation is that we NEED the user to be able to select Case.Type in their own language and then use that value to determine the record type. So, while we might use a map of possible Case.type values to DeveloperName values, we can't simply use the DeveloperName. May 14, 2014 at 15:15
  • Yep, they'll select the type on the translated picklist but in apex it'll be "safe", always in the org's main language (English I assume?). At least unless you say run a query similar to SELECT TOLABEL(Type) FROM Case but then it's assumed you know what you're doing. My point is that with Type being always in English when it hits your trigger and DeveloperName being always the real API name of the record type you could safely build your mapping?
    – eyescream
    May 14, 2014 at 15:34
  • @eyescream, I'm not looking for values to map against, I'm looking for functionality so I don't need to create the map (neither in hardcode or through custom settings)... something like newCase.Type.untranslatedValue()... May 14, 2014 at 16:17

1 Answer 1


Case.Type side

In Apex & API the picklist will always be in the organization's master language. I'm writing it 3rd time ;)

I've flipped my user's lang to German:

Translation Workbench

and this query still returns data in English:


Raw query (Real Force Explorer) Execute Anonymous

You'd have to flip to TOLABEL syntax (and ditch the GROUP BY) to get translated versions:

query with forced translation

So you don't need to "untranslate" the picklist. It'll be always in your orgs main language, period.

Your problem is that RecordTypeInfosByName returns translated data. If EN user happens to mass update Cases raised by EN and FR users - hilarity & null pointers ensue.

Case.RecordTypeId side

Most straightforward method would be to query the table of record types.

SELECT Id, Name, DeveloperName
FROM RecordType
WHERE SobjectType = 'Case' AND IsActive = true

And then build a Map<String, Id> where key would be the DeveloperName and the value would be the Id. Dev. name will not change whereas visible name can be translated (I had lots of "fun" with 'System Administrator' Profile sometimes being returned in Visualforce or queries as 'Systeembeheerder'...)

(this is still somewhat naive and the answer I've linked to in the comments simply rocks)

You'll still have to make some patching between Type and DeveloperName (for example replace spaces with underscores) but I don't see a reason why "always org's master lang" => "always org's master lang" mapping wouldn't work.

  • Ah... I see what you are saying now. A mapping will work, BUT I want to avoid the mapping as to avoid maintaining the mapping as the types and record types we are using are both subject to change. May 15, 2014 at 8:06
  • Does it have to be in a trigger then? Without a hardcoded map or plain rule that says "replace spaces with underscores and give it a go" and without custom settings... Tricky. How about having multiple workflow rules & field updates that will set the Record Type then?
    – eyescream
    May 15, 2014 at 8:37
  • Saying it is in a trigger is putting it simply; moving it to a workflow wouldn't be an option as there is far too much complexity in the surrounding logic. May 15, 2014 at 8:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .