Administrate: Back to app not translated

[betelgeuse]

• What were you trying to do?
  Use administrate with locale different from English
• What did you end up with (logs, or, even better, example apps are great!)?
  Not being able to translate "Back to app"
• What versions are you running?
  master of administrate

The code added in #1376 is missing i18n keys.

[nickcharlton]

Nice catch! I clearly didn't think about that at the time.

Would you be able to open a PR for this?

[betelgeuse]

Would you be able to open a PR for this?

Is there a better way than Google translate to come up with the required translations?

[nickcharlton]

Unfortunately, this is basically what I'd been doing. The other option is to add them in English to all of the translation files, but that's not great either.

In general, I've found people will open PRs to fix translations if they're not very good and so I've been relying on that.

[betelgeuse]

The other option is to add them in English to all of the translation files, but that's not great either.

Adding in English would prevent tools that spot missing translations from working so I would avoid it as an option.

[pablobm]

How about this plan:

1. @betelgeuse creates a PR with the English string and any other languages you may know.
2. We can then ask around people we know for other common languages and add them to the PR.
3. When we feel we have covered some reasonable defaults, we can merge.

I'm not sure how a missing translation would affect people though. I just tried running the example app in Spanish and got an error translation missing: es.views.pagination.next. From this, I'm thinking that people are used to providing missing strings as soon as they see errors. If this is the case, we should be ok.

Thoughts?

[nickcharlton]

I think working with errors is an acceptable trade off, to encourage translation contributions.

[betelgeuse]

I think working with errors is an acceptable trade off, to encourage translation contributions.

Should probably have a README entry saying not to expect locale files to be perfect.

[edimossilva]

How about this plan:

1. @betelgeuse creates a PR with the English string and any other languages you may know.
2. We can then ask around people we know for other common languages and add them to the PR.
3. When we feel we have covered some reasonable defaults, we can merge.

I'm not sure how a missing translation would affect people though. I just tried running the example app in Spanish and got an error translation missing: es.views.pagination.next. From this, I'm thinking that people are used to providing missing strings as soon as they see errors. If this is the case, we should be ok.

Thoughts?

So @pablobm, I also had the same issue in portuguese, it is due to Kaminari Showing /var/lib/gems/2.5.0/gems/kaminari-core-1.2.0/app/views/kaminari/_next_page.html.erb, they don't have the proper translations :(

We have 2 options:

1. solve this issue on kaminari
2. solve it here ( doesn't look a smart choice) creating files like kaminari.pt-BR.yml with content similar to:

pt-BR:
  views:
    pagination:
      first: "« Primeiro"
      last: "Ultimo »"
      previous: "‹ Anterior"
      next: "Proximo ›"
      truncate: "..."

[pablobm]

@betelgeuse - I agree with adding that note to the README.

@edimossilva - From what I see on the Kaminari repo, they don't appear to provide translations for any language. It looks to me as though they expect each application to provide their own. In this case, we'll have to provide it ourselves.

[edimossilva]

@pablobm, so should I create another issue related to kaminari translations?

[pablobm]

@edimossilva - Yes, I think that opening a separate issue would be the right approach.