-
Notifications
You must be signed in to change notification settings - Fork 49
Add mailer locale doc #44
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
Conversation
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.
Not sure we should add this to the readme. If we do add something related to locales, I think it should be a more generic section. Check Devise's I18n section. Something that references a file that contains always up to date translations (the reference a wiki, but pointing to our config/locales
file will be easier to maintain). If you want to write down something similar or just like Devise in this PR, I think we could add it.
Ok, so you think I should move this to an I18n section and put an example like the ones used in the link you posted to show that the user could have something like: en:
graphql_devise:
confirmations:
send_instructions: "Please check '#{email}' for instructions on how to confirm your account" Something like that? |
Yes, something more generic like Devise's, not only for the resend confirmation email. More importantly, provide a link to our file on the repo where they could see ALL the locales they can override |
Ok, I'll look into this, this weekend and update the PR. |
Finally got around to adding a separate section for I18n. |
…phql_devise into add_mailer_locale_doc
Thanks @aarona, this looks like a nice addition. |
Because I pass the email address being confirmed to the response message like so:
I thought that it should be documented for the user in case they wanted to customize the locale to support it. This is supported by Devise even though our locale setting doesn't. The user would have to override the entire mutation to put the email variable in there otherwise which is why I left it in.
I decided to add this documentation as a subset in the Customizing Email Templates section because I felt that was the best place to put it.