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

Support translations for ActiveRecord models #298

Merged
merged 1 commit into from
Dec 7, 2015

Conversation

c-lliope
Copy link
Contributor

@c-lliope c-lliope commented Dec 6, 2015

Problem:

Developers are unable to display their ActiveRecord classes in the UI by
any other name than the titleized class name.

For example, if a team is building an admin dashboard that will be used in
Russian, they may have ActiveRecord models with English names, that need to
be translated before they're displayed in the UI.

Solution:

Rails has support for translating ActiveRecord Models, which relies on
defining I18n translations under the activerecord.models namespace.

Rails expects translations in the form:

en:
 activerecord:
   models:
     user:
       one: Customer
       other: Customers

The separate one and other keys allow Rails to display the correct
plural or singular form of the word, depending on the context.

We've used Rails' built-in ActiveModel::Name#human method to correctly pull
the translations out of I18n, with sane fallbacks if the translation is not
defined.

customer: {
one: "User",
other: "Users",
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Put a comma after the last item of a multiline hash.

@c-lliope
Copy link
Contributor Author

c-lliope commented Dec 6, 2015

This was continued from the work in #180.

@mgrachev
Copy link
Contributor

mgrachev commented Dec 6, 2015

👍

@@ -4,5 +4,17 @@ def render_field(field, locals = {})
locals.merge!(field: field)
render locals: locals, partial: field.to_partial_path
end

def display_resource_name(resource_name)
resource_name.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this just be resource?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would think that "resource" would refer to the whole model object, but that's just me.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I'm siding with @mcmire on this. I've been using resource to refer to instances of the ActiveRecord models. Here, we're referring to the class names of the ActiveRecord models.

I think if we end up going with @mcmire's suggestion in #298 (comment), then we should rename this to resource_class or something.

@danbee
Copy link
Contributor

danbee commented Dec 7, 2015

LGTM! 👍

constantize.
model_name.
human(
count: 0,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this always 0? how do we handle plurals?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JoelQ this dictates how the resource names show up in the sidebar, and in the header on the index page. I think in both of those cases, we always want the displayed name to be in the plural form.

customers___administrate_prototype

I started to code out an argument to this function that would let you specify a custom count, but I think YAGNI applies to that. If we need to display the singular form in the future, we can adjust this method accordingly.

@mcmire
Copy link

mcmire commented Dec 7, 2015

I had one comment, and I would also agree with Joël about why count: 0 is being used above. Other than these two things I'm good with this.

with_translations(:en, translations) do
visit admin_customers_path

sidebar = find(".sidebar__list")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason this has double underscores?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're using BEM syntax for our CSS. In this case, the CSS class would read as: "The list element inside the sidebar block", or something like that.

CSS selector formats are something that we could have a whole other discussion on - I'm still not sure what the best solution is for Administrate. I chose BEM because many designers at thoughtbot have had pleasant experiences working with it, and it makes it a bit easier to write maintainable (S)CSS.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@JoelQ
Copy link
Contributor

JoelQ commented Dec 7, 2015

One comment on a CSS class name, otherwise LGTM 🚀

Problem:

Developers are unable to display their ActiveRecord classes in the UI
by any other name than the titleized class name.

For example,
if a team is building an admin dashboard that will be used in Russian,
they may have ActiveRecord models with English names, that need to be
translated before they're displayed in the UI.

Solution:

Rails has support for [translating ActiveRecord Models][1],
which relies on defining I18n translations
under the `activerecord.models` namespace.

Rails expects translations in the form:

```yaml
en:
  activerecord:
    models:
      user:
        one: Customer
        other: Customers
```

The separate `one` and `other` keys allow Rails to display
the correct plural or singular form of the word,
depending on the context.

We've used Rails' built-in `Foo.model_name.human` method
to correctly pull the translations out of I18n,
with sane fallbacks if the translation is not defined.

[1]: http://guides.rubyonrails.org/i18n.html#translations-for-active-record-models
@c-lliope c-lliope force-pushed the gw-activerecord-translations branch from 14702eb to c75b572 Compare December 7, 2015 18:57
@c-lliope c-lliope merged commit c75b572 into master Dec 7, 2015
@c-lliope c-lliope deleted the gw-activerecord-translations branch December 7, 2015 18:58
@c-lliope c-lliope removed the In Review label Dec 7, 2015
@c-lliope c-lliope added this to the v0.1.2 milestone Dec 7, 2015
@mgrachev
Copy link
Contributor

mgrachev commented Dec 7, 2015

🎉

c-lliope added a commit that referenced this pull request Dec 9, 2015
Changes:

```
* [#251] [FEATURE] Raise a helpful error when an attribute is missing from
  `ATTRIBUTE_TYPES`
* [#298] [FEATURE] Support ActiveRecord model I18n translations
* [#312] [FEATURE] Add a `nil` option to `belongs_to` form fields
* [#231] [UI] Fix layout issue on show page where a long label next to an empty
  value would cause following fields on the page to be mis-aligned.
* [#309] [UI] Fix layout issue in datetime pickers where months and years
  would not wrap correctly.
* [#306] [UI] Wrap long text lines (on word breaks) on show pages
* [#214] [UI] Improve header layout when there is a long page title
* [#198] [UI] Improve spacing around bottom link in sidebar
* [#206] [UI] Left-align checkboxes in boolean form fields
* [#315] [UI] Remove the `IDS` suffix for `HasMany` form field labels
* [#259] [BUGFIX] Make installation generator more robust
  by ignoring dynamically generated, unnamed models
* [#243] [BUGFIX] Fix up a "Show" button on the edit page that was not using the
  `display_resource` method.
* [#248] [BUGFIX] Improve polymorphic relationship's dashboard class detection.
* [#247] [BUGFIX] Populate `has_many` and `belongs_to` select boxes
  with the current value of the relationship.
* [#217] [I18n] Dutch
* [#263] [I18n] Swedish
* [#272] [I18n] Danish
* [#270] [I18n] Don't apologize about missing relationship support.
* [#237] [I18n] Fix broken paths for several I18n files (de, es, fr, pt-BR, vi).
* [#266] [OPTIM] Save a few database queries by using cached counts
```
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

Successfully merging this pull request may close these issues.

6 participants