-
-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hard-coded English text strings should be moved to their language files #114
Conversation
Great stuff, thanks! The localization files being overly fragmented is a remnant from starting with the starter site I started with. It's been on my list of things to fix and tighten up (like the frontend/backend business, since there is no real front end for this app), but hadn't gotten around to it. I'm not sure what you mean about alpha_space. alpha space comes with Laravel as a provided filter. I believe I created alpha_dash, which is more lenient and allows more special characters (but doesn't allow characters that could be used for XSS attacks.) |
As for "alpha_space", I found these model classes:
maybe more. |
Yeah, I know where they are, I'm just not sure what you mean by "I think this sould be removed or at least be replaced with regexp for non-English users." If we were going to replace validation, that's fine, but we can't just remove it. Validation exists for a reason. If you'd like to take a stab at creating a new filter that is more international-friendly, that's cool, as long as the rest of the general validation rules apply (i.e. alpha contains only letters, not spaces). What did you have in mind specifically? Allowing accented characters to start? I think it will get hairier in a whitelisted context if we start looking at kanji, etc, but open to discussion about it. I'm not sure how regex ranges work with kanji or if they do at all. Validator::extend('alpha_space', function($attribute,$value,$parameters) |
I understand that you want to be sure XSS vunlerable characters not be accepted. But what about model fields that don't have any validation at all, e.g. order number in Asset class. And one more; model_id field is just a select field and there's no character-level validation. So you can inject any dangerous characters by forging that field values if you really want to. I think the best we can do are 1. escape or encode any html-allowed fields in views when outputing, 2. filters are just data format filters, you should not rely on those for security of your application. So, for no. 1, Laravel supports this:
For no. 2, I think alpha_space or alpha_XXX are too limited for international users. Maybe we can have this RegExp as an alpha_space anternative (unicode space and letters).
or considering unicode "separator" characters
|
I found most of view files and controllers were not localization-ready. So here's my little contribution to move hard-coded literal strings to language files. I think I've done only 10 percent of localization but I think I need to discuss my localization with other contributors.
form.php
language files to localize creation and edit forms.table.php
s andform.php
s?If you like my localization I'll continue to work more.