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
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.
Describe alternatives you’ve considered
NA
Additional context
NA