Is there a good way to "untranslate" picklists in Apex?

Question

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?

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:

and this query still returns data in English:

SELECT Type
FROM Case
GROUP BY Type
LIMIT 5

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

---

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.