Split i18n templates

[goosys]

I’m a Japanese speaker, and we’ve had to implement a variety of customizations in order to make our application work well in Japanese.
Many of the translate calls in Administrate’s templates are optimized for alphabet-based languages, and they include transformations that are unnecessary (and sometimes undesirable) for us.

As our i18n customizations grew, upgrading Administrate became increasingly painful because we had to manually update many templates to match the latest version.
I’ve been thinking for years about whether there might be a better approach.

So here’s my proposal:
What would you think about splitting the templates in the following way?

• Extract all translated UI elements into files under administrate/i18n/*.
• Load them using render partial: ....
• Application developers can then copy those templates and provide locale-specific versions such as i18n/_resource_item_label.ja.html.erb.
• Administrate itself would not attempt to support those customized locale templates beyond this mechanism.

This would also address issues like #1783.
If someone wants to apply German-style capitalization, they can simply create a .de.html.erb version and implement it however they like.
There was also a question somewhere about supporting right-to-left languages — with this approach, developers could handle that entirely within their own locale templates.
(For reference, in Japanese we don’t want pluralization or capitalization at all, so we would prefer to use just human_attribute_name with no additional transformations.)

I'd love to hear what you think!

Here is my experiment with this idea:
8b7da90

[pablobm]

I've been thinking about this and wondering what would be the "conventional" way to do it. My current opinion is that we should do something like what ActiveRecord does to translate model and attribute names.

So we would have new translation string that would include the name of the resource class. For example:

en:
  administrate:
    actions:
      models:
        log_entry:
          new_resource: "You are about to create a Log Entry"

Not sure about the exact format; could be different.

The problem here would be back compatibility. Currently we have administrate.actions.new_resource. The above example would change this to administrate.actions.models.#{page.resource_name}.new_resource, breaking existing code. We would need an internal mechanism to see if one exists, fall back on the other if not.

Also: in many cases New %{name} is just ok, covering most if not all cases. If we introduce this new option, we probably would want a default that applies when nothing else is available. Perhaps like this:

en:
  administrate:
    actions:
      models:
        _default_:
	      new_resource: New %{name}
        log_entry:
          new_resource: "You are about to create a Log Entry"

Thoughts?

[goosys]

@pablobm
No — while that’s a very simple idea, it doesn’t actually solve the problem.

Rails i18n supports variable interpolation, but it doesn’t support transformations.
Because of that, we can’t handle language-specific requirements—such as whether a model name should be plural or singular, capitalized, titleized, or lowercased—using i18n YAML alone.

Due to this limitation, if we try to solve everything with i18n alone, we end up passing all combinations (plural, singular, capitalized, etc.) as arguments to i18n.t().

For example:

t(
  "administrate.actions.new_resource",
  name: display_resource_name(page.resource_name, singular: true),
  name_singular_downcase: display_resource_name(page.resource_name, singular: true).downcase,
  name_singular_capitalize: display_resource_name(page.resource_name, singular: true).capitalize,
  name_plural_downcase: display_resource_name(page.resource_name, singular: true).plural.downcase,
  name_plural_capitalize: display_resource_name(page.resource_name, singular: true).plural.capitalize,
  ...
)

That leads to usages like New %{name_singular_downcase} or %{name_singular_capitalize} erstellen.

I can’t even imagine how many combinations this would grow into, and for applications that use only a single language, most of this becomes unnecessary computational overhead.

I don’t claim that my proposal is the best possible solution yet, but I do believe this can’t be solved with i18n.t alone.

What do you think?

[pablobm]

It's ok: with my solution we would send only name. No need to send singular, plural, etc. Let's see an example.

Say we have this:

en:
  administrate:
    actions:
      models:
        _default_:
	      new_resource: New %{name}
        log_entry:
          new_resource: "Filing an entry in the log"

And say we call it like this, with a helper administrate_t (for example) that checks what's available and chooses the right translation key. We only provide name and nothing else:

administrate_t("administrate.actions.#{resource_class_name}.new_resource", name: resource_class_name)

Then we get these results:

• With resource_class_name = "log_entry":
  • We get "Filing an entry in the log".
  • In this case it uses the log_entry key.
• With resource_class_name = "user":
  • We get "New user"
  • The helper administrate_t sees that there is no administrate.actions.models.user and chooses _default_

Since we have a separate key in the yml for each model, we can adjust plural/singular/etc ourselves manually there.

Happy to play with other examples! I want to see where this exactly fails.

[goosys]

@pablobm
No. We already define translations for models and attributes using ActiveRecord’s i18n.
Writing all of those translations again just for Administrate isn’t realistic.

ja:
  activerecord:
    models:
      log_entry: ログ # LogEntry.model_name.human -> 'ログ'
      user: ユーザー # User.model_name.human -> 'ユーザー'
      ...

  administrate:
    actions:
      models:
        _default_:
          new_resource: "%{name} を作成" # -> `userを作成` is not what we want
        log_entry:
          new_resource: "ログを作成"
        user:
          new_resource: "ユーザーを作成"
        ...

In our language, we simply want to pass resource_class.model_name.human as the %{name}.
I imagine the situation varies a lot across languages.

To support that, I think we need some way for each app to customize administrate_t per locale—whether that’s extracting the logic into views, allowing locale-specific helpers, using something like a RenderableObject, or some other approach.