# Better NLS and Backend Widget Processing Suggestion

**URL:** <https://devforum.zoom.us/t/better-nls-and-backend-widget-processing-suggestion/41538>\
**Category:** Feature Requests\
**Created:** [January 25, 2021, 8:46pm UTC](https://devforum.zoom.us/t/better-nls-and-backend-widget-processing-suggestion/41538 "2021-01-25T20:46:23Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![breynoldszoom](https://avatars.discourse-cdn.com/v4/letter/b/a88e57/32.png) [@breynoldszoom](https://devforum.zoom.us/u/breynoldszoom)\
**Post date:** [January 25, 2021, 8:46pm UTC](https://devforum.zoom.us/t/better-nls-and-backend-widget-processing-suggestion/41538/1 "2021-01-25T20:46:23Z")

</div>

**Is your feature request related to a problem? Please describe.**  
The “key” field in the API design for widgets is doing double duty as a label.  
This leads to an unnecessary burden on develpers of NLS aware systems.

**Describe the solution you’d like**  
Add an ‘internalKey’ field to better enable National Language Support (NLS)  
and disambiguate values in the backend. For example, the page at

[https://marketplace.zoom.us/docs/api-reference/webhook-reference/chatbot-events/form-fields](https://marketplace.zoom.us/docs/api-reference/webhook-reference/chatbot-events/form-fields)

has an example which includes this field,  
{  
“editable”: true,  
“value”: “Zoom”,  
“key”: “Company”  
}

(I changed the editable value for this discussion).

The “key” is used as the label and the “value” is the initial value.

The interactive\_message\_fields\_editable POST event would then have

“fieldEditItem”: {  
“currentValue”: “Zoom”,  
“key”: “Company”,  
“newValue”: “Acme Widgets”  
},

Now, consider a bot supporting users worldwide. The bot’s backend  
has to cross reference something in order to determine the various field values.  
Currently that must be the “key” field. However, that field is doing  
double duty as the label. For a user in the USA the field may be labelled  
“Name” while for someone in France “Nom”.  
As a result the backend needs to be aware of the label\key.

The proposal is to have an “internalKey” field which identifies  
the field values no matter the user’s language and label. In this situation  
the “key” is relegated to being only used for the label. The backend  
can focus on processing the “fullName” no matter the NLS in play.

For the USA user,  
{  
“editable”: true,  
“value”: “John Doe”,  
“key”: “Your Full Name”,  
“internalKey” :“fullName”  
}  
For the French user,  
{  
“editable”: true,  
“value”: “John Doe”,  
“key”: “Ton nom complet”,  
“internalKey” :“fullName”  
}

For the Spanish user,  
{  
“editable”: true,  
“value”: “John Doe”,  
“key”: “tu nombre completo”,  
“internalKey” :“fullName”  
}

The interactive\_message\_fields\_editable POST event would then have  
the following independent of the NLS label (the former key value),

“fieldEditItem”: {  
“currentValue”: “”,  
“internalKey”: “fullName”,  
“newValue”: “John Doe”  
},

I have another comment re: drop downs which states the multiple  
drop downs on the same form can not be distinguished from one another  
in interaction notifications. The “internalKey” notion could be  
applied to this area as well. Buttons could benefit from this too.

> [@Chatbot - How to disambiguate selections across multiple drop downs](https://devforum.zoom.us/t/chatbot-differentiate-between-2-drop-down-selections/41385):
>
> Description We have a simple use case for the bot to prompt for several pieces of information. The form is shown to the user for him or her to fill out and then click either the Cancel or OK button. For example, consider a form-like message with 2 editable fields and 2 drop downs such as First name [\_\_editable\_\_] Last name [\_\_editable\_\_] Likes beer [\_\_Yes | No\_\_ |\/] Favorite color [\_\_Red |Blue|Green|Black\_\_ |\/] (Cancel) (OK) How is the developer supposed to distinguish …

**Describe alternatives you’ve considered**  
NA

**Additional context**  
NA