Remove label for ToggleSwitch, breaks i18n

[bolinfest]

Describe the bug
A clear and concise description of what the bug is.

Creating a <ToggleSwitch> forcibly displays an "On" or "Off" label. The only documented options for statusLabelPosition are start and end. How about offering none and make it the default?

To Reproduce
Create a <ToggleSwitch>. "On" vs. "Off" is displayed to match the state of the switch.

Expected behavior
No label should be displayed. Only the application owner knows the language of the host page, the vocabulary the app is using to describe the state controlled by the switch, what font size/color should be used to be consistent with the rest of the app, etc.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: macOS
• Browser Chrome
• Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/101.0.4951.64 Safari/537.36

Additional context
While we're discussing the API, onClick does not seem like a great API name. It suggests the event handler is not appropriate on touch devices. I don't care whether the user used a mouse, keyboard, or their finger to toggle the state: I want one event handler where I respond to the state change that results from the input event.

[bolinfest]

/cc @mperrotti who I believed introduced this as part of #1933

[bolinfest]

Also, this appears to be the code:

        <Box textAlign="right" sx={isOn ? null : hiddenTextStyles}>
          On
        </Box>
        <Box textAlign="right" sx={isOn ? hiddenTextStyles : null}>
          Off
        </Box>

As this does not use <Text> it doesn't support themes. It seems like this could just be:

<Box textAlign="right">
  <Text>{isOn ? 'On' : 'Off'}</Text>
</Box>

though again, it would be better if it did not exist at all.

[mperrotti]

No label should be displayed. Only the application owner knows the language of the host page

You're absolutely right about the i18n issue. Supporting translated strings wherever we have something hard-coded is a known issue. However, we intentionally designed the component so that "On" and "Off" must be rendered with the component.

---

onClick does not seem like a great API name. It suggests the event handler is not appropriate on touch devices

onClick is just the standard React prop name for both taps and clicks. I think it would feel more strange to call it something else.

---

It seems like this could just be:
<Box textAlign="right"> <Text>{isOn ? 'On' : 'Off'}</Text> </Box>

We intentionally render both "On" and "Off" to prevent a layout shift when the text changes.

[bolinfest]

However, we intentionally designed the component so that "On" and "Off" must be rendered with the component.

So you are unwilling to support an option to render the component without the label?

[bolinfest]

Not having this option would be an unfortunate reason for me to have to fork the component locally, but if that's the decision, I'll go ahead with that then.

[mperrotti]

@bolinfest - no need to fork. There is a workaround you can do with the sx prop until we figure out our i18n/translation strategy for hard-coded strings.

<ToggleSwitch sx={{'> [aria-hidden]': {display: 'none'}}} />

[bolinfest]

@mperrotti Thanks: that works just fine for now!

[rezrah]

Closing as a workaround has been accepted.