-
Notifications
You must be signed in to change notification settings - Fork 21.4k
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
Add ".[key]" to the abstract namespaces [ci skip] #50860
Conversation
The section "Error Message Scopes" describes how the Rails look up the namespaces for a validation error message with code snippets. The first code snippet shows abstract namespaces like `errors.attributes.[attribute_name]` while the second one demonstrates the materialized one like `errors.attributes.name.blank`. The first code snippet lacks the validation error "key." My team member was confused and created a translation without "key", so I think it would be helpful to add ".[key]" to the abstract namespaces.
guides/source/i18n.md
Outdated
@@ -918,11 +918,11 @@ end | |||
The key for the error message in this case is `:blank`. Active Record will look up this key in the namespaces: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the idea makes sense but now the example doesn't fit with this line introducing it. When .[key]
is included the list is no longer a list of namespaces, its a list of the exact keys going to be checked
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your advice. It makes sense. I updated with 6f56e37, and moved abstract list after :blank
examples. Besides, I changed the wording.
* Add ".[key]" to the abstract namespaces [ci skip] The section "Error Message Scopes" describes how the Rails look up the namespaces for a validation error message with code snippets. The first code snippet shows abstract namespaces like `errors.attributes.[attribute_name]` while the second one demonstrates the materialized one like `errors.attributes.name.blank`. The first code snippet lacks the validation error "key." My team member was confused and created a translation without "key", so I think it would be helpful to add ".[key]" to the abstract namespaces. * Move abstract key list after :blank examples Co-authored-by: Rafael Mendonça França <rafael@rubyonrails.org>
* Add ".[key]" to the abstract namespaces [ci skip] The section "Error Message Scopes" describes how the Rails look up the namespaces for a validation error message with code snippets. The first code snippet shows abstract namespaces like `errors.attributes.[attribute_name]` while the second one demonstrates the materialized one like `errors.attributes.name.blank`. The first code snippet lacks the validation error "key." My team member was confused and created a translation without "key", so I think it would be helpful to add ".[key]" to the abstract namespaces. * Move abstract key list after :blank examples Co-authored-by: Rafael Mendonça França <rafael@rubyonrails.org>
Motivation / Background
The section "Error Message Scopes" describes how the Rails look up the namespaces for a validation error message with code snippets. The first code snippet shows abstract namespaces like
errors.attributes.[attribute_name]
while the second one demonstrates the materialized one likeerrors.attributes.name.blank
. The first code snippet lacks the validation error "key." My team member was confused and created a translation without "key", so I think it would be helpful to add ".[key]" to the abstract namespaces.Checklist
Before submitting the PR make sure the following are checked:
[ ] This Pull Request is related to one change. Changes that are unrelated should be opened in separate PRs.[Fix #issue-number]
[ ] Tests are added or updated if you fix a bug or add a feature.[ ] CHANGELOG files are updated for the changed libraries if there is a behavior change or additional feature. Minor bug fixes and documentation changes should not be included.