Skip to content
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

feature: Translations for Rails::Generators #1008

Open
jpgeek opened this issue Jul 31, 2022 · 7 comments
Open

feature: Translations for Rails::Generators #1008

jpgeek opened this issue Jul 31, 2022 · 7 comments
Assignees

Comments

@jpgeek
Copy link

jpgeek commented Jul 31, 2022

Translations for Rails generators and scaffolding would seem to fit in the scope of rails-i18n, but seem to be only partially included. For example in the

controller template:

notice: <%= %("#{human_name} was successfully created.") %>

or in new

<%%= link_to "Back to <%= human_name.pluralize.downcase %>", <%= index_helper(type: :path) %> %>

Oddly, it looks like there are currently translations for errors within the templates at errors.template.header for some template strings, but not success, back, or destroy. How about adding a section for template.errors.* and template.messages.* to handle these cases?

This is similar to issue #784 but generalizes it.

@digitalfrost
Copy link
Collaborator

@jpgeek thank you - this ticket is a lot clearer than #784

@jpgeek
Copy link
Author

jpgeek commented Aug 18, 2022

@digitalfrost thank you for the update cleanup on the issues.
If this is something that you and the other maintainers feel is in-scope, I would be happy to suggest a scope, put in a PR and provide translations for en and ja. If it is out of scope I will extract the scaffold translations into another gem and we can close this feature.

@digitalfrost
Copy link
Collaborator

@kuroda and @pama - Could you please give feedback.
To me this seems like a good idea.

@pama
Copy link
Collaborator

pama commented Aug 23, 2022

I have some concerns.

First, it should be optional to avoid breaking existing code/workflow, and #1019 could be a starting point to accomplish that.

Second, it concerns me that by introducing this change, we will also need to maintain the scaffold code, which seems somehow out of scope.

@jpgeek
Copy link
Author

jpgeek commented Nov 17, 2022

Thanks @pama.
So using #1019 we could put the scaffold translations under rails/scaffold. That makes sense.

As to your second point, wouldn't the scaffold code still be the responsibility of the scaffold (railties) team, just like it is for say ActiveRecord? For example with Active Record, the I18n scope is determined in the Rails code:
here
If we can get the scaffold (railties) team to come up with the namespace (or we suggest one) would that work?

@pama
Copy link
Collaborator

pama commented May 12, 2023

I would prefer to view the scaffold code in the Ruby on Rails source, allowing us to provide translations through rails-i18n.

I am not inclined to maintain a separate scaffold branch in this gem. I recommend initiating a discussion on https://discuss.rubyonrails.org/c/rubyonrails-core/5.

@jpgeek
Copy link
Author

jpgeek commented Jun 12, 2023

Thank you @pama . I opened a discussion there last year:
here
No replies yet. Does not look like it will happen there either.

@kuroda kuroda removed their assignment Jun 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants