How to make theme translations work properly?

I’m currently trying to set theme translations in order to replace some hard coded strings by variable values.

I’m following step by step the documentation (which theoretically seems very simple). I’ve created a file named languages.yaml at the root of the theme which contains this test value:

    FEED: "Subscribe RSS"
    FEED: "Abonnement RSS"

Next, I’m trying to display this value in an element inserted in the base.html.twig file this way:

<p>Translation must come here: {{ 'THEME_THEMENAME.FEED' | tu }}</p>

But only the hard coded text Translation must come here: appears…

I tried to use double or single quotes, to clear the cache, to set a languages directory with one file per language: nothing helps. The value is not displayed.

I suppose I have missed a part of the process. Thanks to everyone who would tell me what I forgot to do…

@gizmecano, Should it not be:

<p>Translation must come here: {{ 'THEME_THEMENAME.FEED' | t }}</p>

Just in case… THEME_THEMENAME is a placeholder and should be replaced by the name of your theme.

You are absolutely right, but it’s a typo in my post and not in my code (I have to correct my initial post).

Nevertheless, as I noted you have used | t and not | tu as I did before, I’ve just tried with this option: now, it’s the key of the value THEME_THEMENAME.FEED which is displayed and not the content of the value…

@gizmecano, When using {{ 'THEME_THEMENAME.FEED' | t }} and the translation filter cannot find the string ‘THEME_THEMENAME.FEED’ in (any) languages.yaml (or ‘user/languages/en.yaml’), it will return the string itself.

I tried the following in theme Quark:

  • Added the following to ‘user/themes/quark/languages.yaml’
        FEED: "Subscribe RSS"
  • Added the following to ‘user/themes/quark/templates/partials/base.html.twig’
    <p>{{ 'THEME_THEMENAME.FEED' | t }}</p>
  • Result:
    <p>Subscribe RSS</p>

When does it go wrong:

  • When I made a typo in languages.yaml or twig,
  • or the file ‘languages.yaml’ cannot be found

@pamtbaau: First of all, thank you for your explanations and your own tests.

I think the problem you pointed out about using the | t and not | tu is a good first step. :+1:

When I made a typo in languages.yaml or twig,

The content of languages.yaml is exactly the one that I pasted in my initial message. As for the inclusion in the TWIG file, it fits well with the key and value stored in the YAML.

or the file ‘languages.yaml’ cannot be found

Currently, my languages.yaml is set at this path : user\themes\themename\languages.yaml, which seems to exactly match the position you specify for the Quark theme.

When […] the translation filter cannot find the string in (any) languages.yaml (or ‘user/languages/en.yaml’), it will return the string itself.

Reading your comments (and especially this passage), I therefore deduce that my languages.yaml file (although it seems to be set in the right path) doesn’t seem to be found by the system, which returns the name of the string instead of its content.

I suppose I will have to test with the option using a <languages> folder and separate files by languages.

Anyway, I have to try to find why this file is not found by the system…

@gizmecano, To be honest, I have no idea what is happening. The only suggestion I can think of at the moment is installing a fresh Grav installation and replay my steps using Quark and see what happens.

If translations are working in the fresh install, make small changes step by step.

I have identified my issue: it was not related to the theme files itselves, but to the previous settings of my test blog (which was initially set for a theme without any translation string).

So, the answer was just below in the documention. To properly run, the system.yaml of the website must avec these settings:

  translations: true

It was elementary: too focused on the theme development, I had not thought to look at the site settings.


1 Like

@gizmecano, Good catch!

The setting translations is true by default and I guess that means it doesn’t hurt when a site is not multilingual. Therefor, I would never have the inclination to set it to false…

At the present time, I think like you. This setting dates from a time when I encountered concerns in order to correctly set a default language.