Dashboard generator misbehaves with translated content

What would you like to be able to do? Can you provide some examples?

I started adding Administrate to my bilingual app when I was also using Globalize. In terms of modelling, Globalize stores the translations on a separate table, but conceptually the attributes are those of the parent model. However Administrate is not aware of this so I ended up in a situation when I had two dashboards and two controllers (with some workarounds because Administrate has some bugs with namespaced models).

So this whole time I was using this working, albeit complicated system where every model's data was split between two dashboards: one for untranslated attributes and one for translated attributes. The translated attributes were linked from the base dashboard using a NestedHasMany field, which got the job done (translations: Field::NestedHasMany.with_options(class_name: "Post::Translation")).

However now that I want to migrate from Globalize to Mobility with a key-value i18n backend, it made me realize that Administrate should in fact not generate dashboards this way, but keep the translated attributes in the main dashboard. The fact that those attributes are stored in a separate table, in a polymorphic key-value table, in a JSONB column, or somewhere else, is an "implementation detail" which shouldn't impact the way the dashboards are structured and the API gets queried.

Now I've re-combined all the dashboards together and the dashboard definitions became much cleaner.

As now the different translations don't show up at the same time any more, I've added a language switcher to the navigation. I use route_translator and added this to the navigation:

<% (I18n.available_locales - [I18n.locale]).each do |locale| %>
  <% I18n.with_locale(locale) do %>
    <% if @requested_resource.try(:to_param) %>
      <% url_params = [:admin, @requested_resource, **request.query_parameters] %>
    <% else %>
      <% url_params = { path_locale: locale.to_s, **request.query_parameters } %>
    <% end %>
    <%= link_to t("common.language"), url_for(url_params), class: "button button--alt" %>
  <% end %>
<% end %>

(One thing I have not yet figured out, is how to ensure that the search bar works again. Now for example if I have a translated title attribute, it throws:)

LINE 1: ... AS CHAR(256))) LIKE '%hello%' OR LOWER(CAST("posts"."t...

Anyway, so it would be great if Administrate somehow recognized that the concerned attributes are translation attributes and kept them together with the untranslated ones when generating the dashboards, instead of ending up with two dashboards and two controllers.

I am opening this ticket both to document these "realizations" in the hope it helps someone else, and also as a feature request in case it would be possible for Administrate to generate the dashboards correctly. I don't really need the feature myself any more but others might be thankful not to encounter the above described behaviour.

How could we go about implementing that?

Very good question. How can this be done in a way that is independent enough from the underlying translation implementation?

As with ActionText has_rich_text, translations can be stored in a key-value table linked by a polymorphic relation. (This is what I actually aim to end up with my migrating to Mobility.) So whatever solution works for ActionText might work for this as well.

Can you think of other approaches to the problem?

Maybe just add a warning somewhere like "if you use a translation backend, make sure to fix your dashboards after they have been generated by doing this and that".