search

i18next / i18next-xhr-backend

[deprecated] can be replaced with i18next-http-backend
https://github.com/i18next/i18next-http-backend
MIT License
253 stars 75 forks source link

Escaping Issues #316

Open saraedum opened 5 years ago

saraedum commented 5 years ago

The implementation of readMulti builds the resulting URL by joining arguments with

let url = this.services.interpolator.interpolate(loadPath, { lng: languages.join('+'), ns: namespaces.join('+') });

This causes trouble for me when the namespace contains whitespaces as these can the not be recovered correctly on the backend.

More generally, this is problematic when the namespace contains anything that gets escaped by interpolate. Characters seem to get escaped as the HTML entities which is very confusing to parse on the backend since you would expect URL escaped arguments.

jamuhl commented 5 years ago

you can build your own function: https://github.com/i18next/i18next-xhr-backend/blob/master/src/index.js#L29

saraedum commented 5 years ago

Thanks for the hint. Do you agree that things should be properly escaped as a default though?

jamuhl commented 5 years ago

got no opinion on that...namespaces should be simple - so your case is the first in 7 years...

backends are extra done as plugins to feel needs as user demand...personally I would completely remove multiload

saraedum commented 5 years ago

This would for example be a problem if the namespace names are not in English (which makes sense if the default language is not English) or if they contain spaces. I agree that it's an unfortunate choice for namespaces to contain spaces…

Note that only the escaping of spaces is a problem in the multiload scenario. The general escaping of HTML entities is a problem in the normal code path as well.

Let me try to propose a PR to improve the situation and we can discuss things further :)