When using shouldUnescape soft hyphen (­) is not unescaped

[Kolombiken]

🐛 Bug Report

When using the prop shouldUnescape ­ is not unescaped while other HTML entities like > are.

Found an old issue by @nilsmehlhorn that looks like it was closed since it has been fixed. But maybe there has been a regression?

To Reproduce

A codesandbox example forked from the old issue with updated package versions.

Expected behavior

Expected output is that ­is unescaped as a soft hyphen.

Your Environment

• runtime version: node v16.17.0, Chrome
• react-i18next version: 11.18.6
• i18next version: 21.9.2

[adrai]

Would you like to send a Pull Request to address this? Remember to extend the existing unit tests.

[Kolombiken]

@adrai Yes, maybe. If I can figure out how to fix it. Need to look into it.

[nilsmehlhorn]

In the issue #1435 and it's corresponding pull request #1529 you've mentioned it was decided to enable override of the default unescape behavior (which you can see here https://github.com/i18next/react-i18next/blob/d3247b5c232f5d8c1a154fe5dd0090ca88c82dcf/src/unescape.js) rather than adding additional HTML entities.

So, it's now possible to provide a custom unescape function which respects any HTML entities you like - I'm doing this successfully in a project since the PR was merged. Here's a test showing roughly how to put it into config:

react-i18next/test/trans.render.spec.js

Line 647 in a0eed42

describe('trans with custom unescape', () => {

[Kolombiken]

@nilsmehlhorn This is great! 🎉 Also a lot better than adding HTML entities to a list. Sorry for not understanding that this was the outcome from that old issue.

Maybe what could still be done is an update to the documentation with a clear example? I totally missed that this was possible. Anyway. Closing this now.