5

I'm trying to use Ant to deploy some changes to a sandbox that has been updated to Winter '22.
I'm getting 2 errors from 2 different custom objects that
.objectTranslation -- Error: Invalid characters are used in case value for HEBREW

Neither of those objects are part of this deploy.
Neither of those objects actually have a translation, not in the source sandbox nor in the destination sandbox.

I was able to find this: https://help.salesforce.com/s/articleView?id=release-notes.rn_sfdx_packaging_update_unescaped_characters.htm&type=5&release=234
But that is unhelpful for 2 reasons: this isn't a managed package and those characters don't actually exist in the translation.

EDIT:
I contacted Salesforce support and they have never seen anything like this before either. It's a learning experience for all of us.

Improve this question

1 Answer 1

Reset to default
5

Well, we figured it out.

It turns out that the two objects in question (one of them actually a Custom Setting) had the _ character in their names. The display name, not the API name.
My_Custom_Object and My_Custom_Setting. So what happened was this: the translation system looked for a translation for the name of these objects, and didn't find one. Instead it took the regular display name. But that had one of the new illegal characters in it, a _. And so the error was thrown.

Our solution is actually different for the 2 objects:

For the custom object, we just changed the display name of the object.
My Custom Object

For the custom setting that wasn't enough, we're not sure why. It might be because of the Object Name of the custom setting, that must have the _ char, and maybe the translation is taking from that as well...? Unknown.
Whatever the reason is, the solution was to "translate" the custom setting name.
That however, is easier said than done. No obvious way to do it in the Translation Workbench. So we went into the metadata and modified the My_Custom_Setting__c-iw.objectTranslation file. It does look like there are 2 values there, one for the name of the custom setting and one for the object.

<?xml version="1.0" encoding="UTF-8"?>
<CustomObjectTranslation xmlns="http://soap.sforce.com/2006/04/metadata">
    <caseValues>
        <article>None</article>
        <plural>false</plural>
        <value>My Custom Setting</value>
    </caseValues>
    <caseValues>
        <article>None</article>
        <plural>true</plural>
        <value>My Custom Setting</value> <!--Was My_Custom_Setting-->
    </caseValues>

So now that works.

What is still unexplained is why we had this problem in the first place. This is not a managed package, and according to the release notes linked in the question, this validation only applies to managed packages.

Improve this answer
4
  • Thanks for the detailed answer. Was it related to Winter 22, or was it the first time you were using custom setting names with underscores?
    – David Cheng
    Aug 31, 2021 at 14:29
  • 3
    It was a Winter 22 thing. We've been deploying between these sandboxes for years (refreshed every so often) with no problem. But the destination sandbox had been upgraded to Winter 22, so it was running that validation. It was odd that it triggered the validation for objects not part of the deployment... But that custom setting had been there for over a year.
    – AvailableName
    Aug 31, 2021 at 21:54
  • Same with us too. Had to remove the underscore in ithe value too.
    – markgarg
    Sep 3, 2021 at 8:46
  • Thanks for posting your resolution. We also used underscores in a couple of custom object translations. Removing the underscores resolved the deployment issue for winter 22 sandboxes.
    – Leon
    Sep 6, 2021 at 9:06

You must log in to answer this question.

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