System page translation of header / footer / modules

Hi all,

i looking for a solution to create translations for the system pages.

The system page (search-results.html) is useing the footer.html and header.html. Is there a way to pull the via HubSpot-Backend / Drag-and-Drop-Editor created translations of these?
With {% if request.query_dict.language == ‘en’ %} {% endif %} im able to only make the code visable i want. But how do i access a specific translated version of header/footer/modules?
Best regards

Wanja

Hi @WFabian,

the easiest way to translate specific elements may not be the easiest for non-developers to edit but you could create a “translation.html” file, set your namings in this file like

{% if request.query_dict.language == 'en' %}
 {% set error_404_headline == "Page not found" %}
...
{% elif request.query_dict.language == 'de'%}
 {% set error_404_headline == "Seite nicht gefunden" %}
...
{% endif %}

include this file to all of your pages/modules and work with those variables instead of text.

So your page html looks like this

<!--
 templateType: page
 label: 404
 isAvailableForNewContent: false
-->
{% include 'PATH-TO-VARIABLE-FILE.html' %}
...

{% block body %}
<div class="systempage">
<h1>{{ error_404_headline }}</h1>
</div>

or you can build an overengineered search&replace JavaScript/jQuery solution for this - since I don’t recommend it(because of page performance) I won’t share any code example for that

best,

Anton

Thanks for your answer Anton!
For text that solution works.
How would you suggest to translate the Header and Footer (footer.html / header.html)? Is there a way to pull the translation thats already done for these via the HubSpot backend / Drad and Drop Editor?

Best regards
Wanja

I assume your footer.html and header.html files are globals (they should be), you can easily create translations in the global editor by adding a translation to them. Also - if you have used modules(doesn’t matter if they’re custom or not) you can modify the content for each translation.

For navigations: If your navigation is set up in the settings(Settings->Website-Navigation) you can clone it or create a new one there. In the next step simply select the right menu for each translation.

Important: When creating a translation make sure you select the right language you’re using for your pages.

So if you create your pages for “just” English you have to create the translations in “just” English. If you translate your pages to something like “English-United States” you have to create the translations for “English-United States”…

hope that helps

best,

Anton

The footer.html and header.html are globals.
I used the globals editor to create translations.
What doesnt work is useing the footer.html and header.html in the system templates (search-results.html) because it doesnt pull translations there. It only pulls the main language.
So my question is how to get the header.html and footer.html translations created via global translations working on system pages.
Best regards

Wanja

@WFabian the system pages can only refer to the primary domain language, so if the translations.html has multiple languages, but the domain is DE (German), then the system page will be German for all users.
One solution you could try would be to check the language slug from the referring page, if iti’s used, then the translations functionality could be extended based on {{request.referrer}}

Hi @WFabian,

never done this but here’s an idea:

Since you can access translations via

{% if request.query_dict.language == 'en' %}
...
{% endif %}

how about something like this for systempages

{% if request.query_dict.language == 'en' %}
{# load the whole module with english translations #}
{% email_simple_subscription "email_simple_subscription" 
header="Email Unsubscribe", 
input_help_text="Your email address:", 
input_placeholder="email@example.com", 
button_text="Unsubscribe", 
label="Backup Unsubscribe" 
%}

{% if request.query_dict.language == 'de' %}
{# load the whole module with german translations #}
{% email_simple_subscription "email_simple_subscription" 
header="Email Unsubscribe", 
input_help_text="Deine E-Mail-Addresse:", 
input_placeholder="email@example.com", 
button_text="Abmelden", 
label="Erneut Abmelden" 
%}

...

{% endif %}

or - what I do on a regular basis if the client needs a translation:

cloning the module from the hubspot folder into the theme folder and modifying the translations to my needs.

Also you could rewrite everything with jQuery .replaceWith - but I truly don’t recommend that. Sure it’s a systempage and performance is not that important but still. Done that once since I had to rewrite almost everything - but still don’t recommend it.

best,

Anton

Any global header and footer modules will not translate to a language in the context of the System pages. The body will translate but not the header and footer modules. This is a HubSpot issue at the moment and many users are posting about this. Until HubSpot resolves this, we got around the issue by creating 404 and 500 Web pages, and translated them, and we put in redirects from the system pages to the web pages.

@Jnix284 That is working for the search-results.html where you have a language slug.
On 404 and 500 you dont have that.
Any ideas how to translate them? :slightly_smiling_face:

@WFabian it would require a developer to code the request referrer I previously mentioned.

Essentially, it would look at the language slug from the page that resulted in the 404 and produce the translated page based on that referring slug.

This is not an easy task :wink:

The language slug is working for the search-results.html where you have a language slug.
For the 404 and 500 you dont have have a language slug.
Any idea how to get a translation running for these?
Best regards
Wanja

Any news about this bug?
We have the same problem: global partias (header and footer) are loaded in the main language. For the content translation we use a variable in the search form so I know wich is the current languare and can translate the strings/content on the system page template but not for the global partials.
In domains/language-settings we remove lang slug prefix for the main language and don’t want to activate it.

One solution could be have a parameter in the dnd_module tag to force the language (but I think it’s not possible) or have a dynamic slug prefix for the search page (like using {{content.language.languageTag}}/mysearchslug … again, not tested but don’t think it works)

Hope to get your reply. Thanks