search

conedevelopment / i18n

Push your Laravel translations to the front-end and use them easily with JavaScript.
https://pineco.de/using-laravels-localization-js/
MIT License
129 stars 21 forks source link

Filtering support #19

Closed Flerex closed 2 years ago

Flerex commented 4 years ago

By default, all translations are given to the frontend. This means that translations related to some feature that is not available to every user of the application (for example, an admin panel) could be discovered by just using the developer tools of the browser.

While the current behavior is enough for most cases, it is true that being able to see all translations can potentially become into a security problem, concerning the domain of the application.

To fix this I suggest implementing a filtering feature, which allows us to customize what translations are and are not available to the frontend. This is exactly the same the package https://github.com/tightenco/ziggy does with routes.

My proposal would be the following. The package would have available a configuration file that can set up whitelisting or blacklisting by providing an array of the translation files that should be filtered. According to the filtering configuration, the global languages JS variable would not contain translations for the files filtered out. Using filtered translations would have the same outcome as using a non existent key.

Flerex commented 4 years ago

I think this is also what @sardoj was asking for in #6.

iamgergo commented 4 years ago

Okay, I see and understand the concept. Let me check some filtering alternatives, so I could have a wider view in which direction should we go.

iamgergo commented 2 years ago

Thanks for the issue and the PR. Sorry it took me long to take a decision over this. Thanks for your work, even if I did not merge it.