$translate.instant doesn't apply fallback language translation in case of translateNotFoundIndicators usage since 2.6.0

[shkrobova]

Translation table contains two languages with codes 'en' and 'de', using 'en' as fallback language and 'de' as current.Translation for key exists only for fallback language. Also translateNotFoundIndicators are configured. But when I attempt to get translation using translate filter, I get translation key, which is wrapped into indicators. Expectation is to get fallback language translation.
Issue reproduced in the plunker: example.

[tspaeth]

If your remove the translationNotFoundIndicator it will work correctly. I assume that the translationNotFoundIndicator currently just detects if your active language doesn't contain the key and then print the indicator here.

[knalli]

PR is landed.

[jimmykane]

The resolution of this by e3c2063 has resulted into when an indicator is not set then the id is interpolated and sanitised opposing to the rest of the reject returns where they just call the applyNotFoundIndicators method. Also bypysses the rejection handler translateByHandler.

I will be refactoring this so that it follows the specs of all other calls most important following sanitization strategy and regards to issues: #730 and #1297 and commit: 01fecd0 to be able to resolve #1722

Worth to mention in order to prevent a breaking change.

@shkrobova I need to mention as well that as discussed in #1722 with @knalli I will provide a $sanitizeNotFound opt out for the user.