2

I want to translate my Drupal 8 site to another language.

I have several translatable strings in my custom theme and modules specified via either the t method or {% trans %}.

To translate these I have activated interface translation. I can now find my strings by going to admin/config/regional/translate.

The problem is this page lists all strings including all strings defined by core. For this project I don't want to translate the admin interface, we specifically want it to stay in the default language (English). This means 90% of the strings listed should not be translated.

I know that I can set the admin interface to stay in a certain language by checking a box on the user account settings page, but this only works when on an admin page. When visiting a node in a translated language, the admin toolbar will still be translated if there are translated strings. If this problem could be solved it would probably be the best solution to just have that box checked.

But for now it seems like my only other option is to only translate the strings I want translated and none of the admin strings. To do this I feel like I have to be able to filter the list of strings on the interface translation page somehow. But there is no way to filter out strings based on which theme or module they are defined in. Or is there?

I have seen that there is a context parameter you can pass to the t method or {% trans %}. Maybe if I add a key like "translate" or something here, I could filter out strings with this context and only translate them. The thing is it feels like using the context parameter in the wrong way and it does not seem to be any way to filter by context either.

Does anyone have a good solution for this?

2
  • I have the exact same use case. Were you able to make any progress? Commented Mar 23, 2017 at 6:47
  • I posted a related question here drupal.stackexchange.com/questions/231659/… and here drupal.org/node/2861753 . While this seems like a brute force solution, one option would be to write a custom module, twig extension and schema to provide your own translations (including management UI). Commented Mar 23, 2017 at 6:55

2 Answers 2

3

There is no solution that I'm aware of. You can't change the context of strings in core or contrib modules without changing the code. Which you shouldn't do.

The fact that toolbar doesn't show the english strings if your admin language is english is a big that's trying to be fixed here: https://www.drupal.org/node/2313309

I don't know if that's still doable in 8.x.

2
  • Thanks for linking that issue. I have commented on it to see if there could be any progress on this for 8.x. Feels like the current solution with the "Administration pages language" in it's current form isn't very useful.
    – reekris
    Commented Mar 17, 2016 at 8:05
  • I also found this issue drupal.org/node/2123543. It has a patch that adds filtering the interface translation by context. Using that it makes it a bit easier to filter out which strings to translate. I could add context to all my custom strings and get them translated quite easily. The problem would still be core and contrib modules that outputs any strings to the site. Those would have to be found manually and translated. So I think the better solution would still be to translate all strings and have a setting for "admin language".
    – reekris
    Commented Mar 17, 2016 at 8:12
0

We needed to cater for this use case as well, in particular for landing page content and pages based on twig template overrides/suggestions.

Our solution was to create a new Twig extension called tr.

The class of the extension plugin checks to see if a 'translations' directory exists in the current theme. If it does, it reads the containing YAML translation files into an associative array (en.yml, es.yml, fr.yml etc.)

When {{ tr('source string') }} is called in the twig template, it will check the loaded associative arrays to see if there is a translation available for the current language and requested string. If there is it will return the translated value.

This works for us since in our case we're only translating a fairly short list of values - short strings and labels like 'Read More', 'Learn More', 'Subscribe' etc. The rest of our translated content comes from the content translation of the entities.

Hope this helps...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.