@atul This change significantly alters the behavior described in a diff that introduced this code https://phab.comm.dev/D698. We need to make sure that the new behavior is better before changing it. Do you think the new behavior is better? At least we should check how it looks like in our UI - in this case it probably can be tested by checking how inline sidebar looks like when only one user with a long name responded to it.
As a side note, it's always a good idea to check git blame and see in the original diff what was the intention.

We need to make sure that the new behavior is better before changing it. Do you think the new behavior is better?

I think so? Previously, if the 3-noun and 2-noun representation didn't fit within maxLength, we would go with the 1-noun representation even if it exceeded maxLength. Given that the name of the function is pluralizeAndTrim and that maxLength is an argument, I thought that the original intention was to cap the number of characters to maxLength.

I think this was suggested in D698 as well:

How does this look if it the result of pluralize is really long? If it doesn't look good, we could try to use something different instead of pluralize that tries to limit character length.

At least we should check how it looks like in our UI - in this case it probably can be tested by checking how inline sidebar looks like when only one user with a long name responded to it.

Yeah you're right, I should have looked at different usages in the UI instead of looking at this function in isolation. I'll see what InlineSidebar looks like when a user with a long username responds, and I'll add a response here with what I find.

As a side note, it's always a good idea to check git blame and see in the original diff what was the intention.

Agreed, I should have done that as well.