Jump to content

Use of Translation in Smarty Templates


Andreas Augustin
 Share

Recommended Posts

Hi Andreas,

Here is one way of how I'm doing it in combination with the TemplateEngineFactory + TemplateEngineSmarty modules. Basically I'm storing all my translation keys in a php file "strings.php" using this file as textdomain. Values are translated in the ProcessWire backend. Then I'm using an autoload module which adds a translation function to smarty:

<?php

class SmartyTranslationExtension extends WireData implements Module
{

    /**
     * getModuleInfo is a module required by all modules to tell ProcessWire about them
     *
     * @return array
     *
     */
    public static function getModuleInfo()
    {
        return array(
            'title' => '',
            'version' => 100,
            'summary' => '',
            'singular' => true,
            'autoload' => true,
        );
    }


    /**
     * Initialize the module
     *
     * ProcessWire calls this when the module is loaded. For 'autoload' modules, this will be called
     * when ProcessWire's API is ready. As a result, this is a good place to attach hooks.
     *
     */
    public function init()
    {
        $this->addHookAfter('TemplateEngineSmarty::initSmarty', $this, 'hookSmarty');
    }


    /**
     * Wrapper to return a translation from a given translation file
     * Default keys are in /site/templates/translations/strings.php
     * Note: The translation is returned in the current language of the user object
     *
     * @param string $key
     * @param string $file
     * @return string
     */
    public function txt($key, $file = 'strings')
    {
        $string = __($key, "/site/templates/translations/$file.php");
        // We remove any html encodings to allow HTML tags in our translations
        return wire('sanitizer')->unentities($string);
    }

    public function hookSmarty(HookEvent $event)
    {
        $smarty = $event->arguments('smarty');
        $smarty->registerPlugin('function', 'txt', array($this, 'txtSmarty'));
    }

    public function txtSmarty(array $params, $smarty)
    {
        $file = isset($params['file']) ? $params['file'] : 'strings';
        $key = isset($params['key']) ? $params['key'] : '<MISSING TRANSLATION KEY>';
        return $this->txt($key, $file);
    }

}

 

Now, I can output my translations in a smarty template like this:

{txt key="hello_world"} --> Outputs translation value (DE, EN, FR...) corersponding to hello_world key

Note that this only works if you are using the TemplateEngineFactory module together with smarty as engine.

Hope it helps!

Cheers

  • Like 2
Link to comment
Share on other sites

It is a PHP file containing the translation keys. You could also enter the translation values for the default language, but I prefer to work with keys on code level so I can translate them to different values for each language in the ProcessWire backend

<?php
__('show_video'); // Video ansehen
__('more'); // mehr
__('case_studies'); // Case-Studies
__('call_us_for_advise'); // Rufen Sie uns für eine unverbindliche Beratung an!
__('map'); // Anfahrt
__('contact_form'); // Kontaktformular
__('overview'); // Übersicht

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Similar Content

    • By joeck
      Hi,
      I'm facing the issue where i have a repeater field with a multi language textarea (german & english, german beeing default). In german more blocks should be displayed as in english.
      The textarea field is configured as inherit default language if blank (I don't want to change this since it is the wanted behaviour for all other pages...).
      Now I want to access the unformatted value of the textarea field in the repeater and only show it if it is not empty. Something like this:
      $body = ""; $page->of(false); foreach($page->blocks as $block){ //blocks is repeater field, each block has title and textarea if ($block->textarea->getLanguageValue($user->language)){ $body .= <<<EOD <div> <div class='uk-card uk-card-default uk-card-body'> <h3 class='uk-card-title'>$block->title</h3> $block->textarea </div> </div> EOD; } } $page->of(true); print $body; However this doesn't work: Call to a member function getLanguageValue() on string.
      I also tried the other syntax for getLanguageValue:
      $page->getLanguageValue($language, $field) But I didn't manage to get a unique name of the textarea field in the repeater.
      I looked into the API of FieltypeRepeater but couldn't find anyhting that fixed my issue.
      Any ideas?
    • By humanafterall
      Hi,
      I have a URL field that will sometimes have relative/local URLs on a multilingual site, for example /contact/ 

      However the URL field does not seem to pick up when I'm on another language, for example /fr/ so I'm taken to the default language page for /contact/ rather than /fr/contact/
      Is there a way to make the URL fields play well with a multi-language site?
      Thanks!
       
    • By Crowdland Technology
      Hello everyone.
      I'm having some issues with Greek as default language, because the page name is not created automatically when enter the title of a new page. 
      Any chance to add support for it?
      I found this char mapping that might help on line 188
      https://github.com/elpak/Greeklish-permalink-wordpress/blob/master/greeklish-permalink/greeklish-permalinks.php
      Thank you!

       
      [EDIT]: A solution
      This was easier than we thought, we managed to find a solution by looking at how the sanitizer of page names works. 
      This is how the URL looks with this solution:
       
       
      For ProcessWire 3+ (what we tested) find Modules > Core > InputfieldPageName and under the “Character Replacements” Field you can add the mapping you would like.


      The replacement is not in the Core yet, so adding it for reference. The mapping is adjusted and simplified, and it follows the official Transliteration found here: https://en.wikipedia.org/wiki/Romanization_of_Greek
      α=a
      ά=a
      β=b
      γ=g
      δ=d
      ε=e
      έ=e
      ζ=z
      η=i
      ή=i
      θ=th
      ι=i
      ί=i
      κ=k
      λ=l
      μ=m
      ν=n
      ξ=x
      ο=o
      ό=o
      π=p
      ρ=r
      σ=s
      ς=s
      τ=t
      υ=y
      ύ=y
      ϋ=y
      φ=f
      χ=ch
      ψ=ps
      ω=o
      ώ=o
      Cheers to @PWaddict for also supplying an unofficial mapping and pointing us to the right direction 
      @ryan It would be great if this would be added to the Core sometime in the future and we can assist with further official mappings that are not present in this simplified version.
      Thank you!

      Cheers,
      Elissavet from CrowdLand
    • By MoritzLost
      Sorry for the convoluted title. I have a problem with Process modules that define a custom page using the page key through getModuleInfo (as demonstrated in this excellent tutorial by @bernhard). Those pages are created automatically when the module is installed. The problem is that the title of the page only gets set in the current language. That's not a problem if the current language (language of the superuser who is installing the module) is the default language; if it isn't, the Process page is missing a title in the default language. This has the very awkward effect that a user using the backend in the default language (or any other language) will see an empty entry in the setup menu:

      This screenshot comes from my Cache Control module which includes a Process page. Now I realize the description sounds obscure, but for us it's a common setup: We a multiple bilingual sites where the default language is German and the second language is English. While the clients use the CMS in German, as a developer I prefer the English interface, so whenever I install a Process module I get this problem.
      As a module author, is there a way to handle this situation? I guess it would be possible to use post-installation hooks or create the pages manually, but I very much prefer the declarative approach. The page title is already translatable (through the __ function), but of course at the time of installation there is no translation, and as far as I'm aware it's not possible to ship translations with a module so they are used automatically. Could this situation be handled better in the core? I would prefer if the module installation process would always set the title of the Process page in the default language, instead of the language of the current user.
    • By MoritzLost
      I have recently started to integrate Twig in my ProcessWire projects to have a better separation between logic and views as well as have cleaner, smaller template files as opposed to large multi-purpose PHP-templates. Though there is a Twig module, I have opted to initialize twig manually to have more control over the structure and settings of the twig environment. This is certainly not required to get started, but I find that having no "secret sauce" gives the me as a developer more agency over my code structure, and better insights into how the internals of the libraries I'm using work.
      Framework like Drupal or Craft have their own Twig integration, which comes with some opinionated standards on how to organize your templates. Since Twig is not native to ProcessWire, integrating Twig requires one to build a solid template structure to be able to keep adding pages and partials without repeating oneself or having templates grow to unwieldy proportions. This will be an (opinionated) guide on how to organize your own flexible, extensible template system with ProcessWire and Twig, based on the system I developed for some projects at work.
      Somehow this post got way too long, so I'm splitting it in two parts. I will cover the following topics:
      Part 1: Extendible template structures How to initialize a custom twig environment and integrate it into ProcessWire How to build an extendible base template for pages, and overwrite it for different ProcessWire templates with custom layouts and logic How to build custom section templates based on layout regions and Repeater Matrix content sections Part 2: Custom functionality and integrations How to customize and add functionality to the twig environment How to bundle your custom functionality into a reusable library Thoughts on handling translations A drop-in template & functions for responsive images as a bonus However, I will not include a general introduction to the Twig language. If you are unfamiliar with Twig, read the Twig guide for Template Designers and Twig for Developers and then come back to this tutorial.
      That's a lot of stuff, so let's get started 🙂
      Initializing the Twig environment
      First, we need to install Twig. If you set up your site as described in my tutorial on setting up Composer, you can simply install it as a dependency:
      composer require "twig/twig:^2.0" I'll initialize the twig environment inside a prependTemplateFile and call the main render function inside the appendTemplateFile. You can use this in your config.php:
      $config->prependTemplateFile = '_init.php'; $config->appendTemplateFile = '_main.php'; Twig needs two things: A FilesystemLoader to load the templates and an Environment to render them. The FilesystemLoader needs the path to the twig template folder. I'll put my templates inside site/twig:
      $twig_main_dir = $config->paths->site . 'twig'; $twig_loader = new \Twig\Loader\FilesystemLoader($twig_main_dir); As for the environment, there are a few options to consider:
      $twig_env = new \Twig\Environment( $twig_loader, [ 'cache' => $config->paths->cache . 'twig', 'debug' => $config->debug, 'auto_reload' => $config->debug, 'strict_variables' => false, 'autoescape' => true, ] ); if ($config->debug) { $twig_env->addExtension(new \Twig\Extension\DebugExtension()); } Make sure to include a cache directory, or twig can't cache the compiled templates. The development settings (debug, auto_reload) will be dependent on the ProcessWire debug mode. I turned strict_variables off, since it's easier to check for non-existing and non-empty fields with some parts of the ProcessWire API. You need to decide on an escaping strategy. You can either use the autoescape function of twig, or use textformatters to filter out HTML tags (you can't use both, as it will double escape entities, which will result in a broken frontend). I'm using twig's inbuilt autoescaping, as it's more secure and I don't have to add the HTML entities filter for every single field. This means pretty much no field should use any entity encoding textformatter. I also added the Debug Extension when $config->debug is active. This way, you can use the dump function, which makes debugging templates much easier. Now, all that's left is to add a few handy global variables that all templates will have access to, and initialize an empty array to hold additional variables defined by the individual ProcessWire templates.
      // add the most important fuel variables to the environment foreach (['page', 'pages', 'config', 'user', 'languages', 'sanitizer'] as $variable) { $twig_env->addGlobal($variable, wire($variable)); }; $twig_env->addGlobal('homepage', $pages->get('/')); $twig_env->addGlobal('settings', $pages->get('/site-settings/')); // each template can add custom variables to this, it // will be passed down to the page template $variables = []; This includes most common fuel variables from ProcessWire, but not all of them. You could also just iterate over all fuel variables and add them all, but I prefer to include only those I will actually need in my templates. The "settings" variable I'm including is simply one page that holds a couple of common settings specific to the site, such as the site logo and site name.
      Page templates
      By default, ProcessWire loads a PHP file in the site/templates folder with the same name of the template of the current page; so for a project template/page, that would be site/templates/project.php. In this setup, those files will only include logic and preprocessing that is required for the current page, while the Twig templates will be responsible for actually rendering the markup. We'll get back to the PHP template file later, but for the moment, it can be empty (it just needs to exist, otherwise ProcessWire won't load the page at all).
      For our main template, we want to have a base html skeleton that all sites inherit, as well as multiple default regions (header, navigation, content, footer, ...) that each template can overwrite as needed. I'll make heavy use of block inheritance for this, so make sure you understand how that works in twig.
      For example, here's a simplified version of the html skeleton I used for a recent project:
      {# site/twig/pages/page.twig #} <!doctype html> <html lang="en" dir="ltr"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>{% block title %}{{ '%s | %s'|format(page.get('title'), homepage.title) }}{% endblock %}</title> <link rel="stylesheet" type="text/css" href="{{ config.urls.site }}css/main.css"> </head> <body class="{{ page.template }}"> {% block navigation %}{{ include("components/navigation.twig") }}{% endblock %} {% block header %}{{ include("components/header.twig") }}{% endblock %} {% block before_content %}{% endblock %} {% block content %} {# Default content #} {% endblock %} {% block after_content %}{% endblock %} {% block footer %}{{ include("components/footer.twig") }}{% endblock %} </body> </html> All layout regions are defined as twig blocks, so each page template can override them individually, without having to touch those it doesn't need. I'll fill the content block with default content soon, but for now this will do. Now, templates for our content types can just extend this base. This is the template for the homepage:
      {# site/twig/templates/pages/page--home.twig #} {% extends "pages/page.twig" %} {# No pipe-seperated site name on the homepage #} {% block title page.get('title') %} {# The default header isn't used on the homepage #} {% block header %}{% endblock %} {# The homepage has a custom slider instead of the normal header #} {% block before_content %} {{ include('sections/section--homepage-slider.twig', { classes: ['section--homepage-slider'] }) }} {% endblock %} Note that I don't do most of the actual html markup in the page templates, but in individual section templates (e.g. section--homepage-slider.twig) that can be reused across content types. More on this in the next section.
      We still need to actually render the template. The page template (which will be the entry point for twig) will be loaded in our _main.php, which we defined as the appendTemplateFile earlier, so it will always be included after the template specific PHP file.
      $template_file = 'pages/page--' . $page->template->name . '.twig'; $twig_template = file_exists($twig_main_dir . '/' . $template_file) ? $template_file : 'pages/page.twig'; echo $twig_env->render($twig_template, $variables); This function checks if a specific template for the current content type exists (e.g. pages/page--home.twig) and falls back to the default page template if it doesn't (e.g. pages/page.twig). This way, if you want a blank slate for a specific content type, you can just write a twig template that doesn't extend page.twig, and you will get a blank page ready to be filled with whatever you want.
      Note that it passes the $variables we initialized in the _init.php. This way, if you need to do any preprocessing or data crunching for this request, you can do it inside the PHP template and include the results in the $variables array.
      At this point, you can start building your default components (header, footer, navigation, et c.) and they will be included on every site that extends the base page template.
      Custom sections
      Now we've done a great deal of setup but haven't actually written much markup yet. But now that we have a solid foundation, we can add layout components very easily. For most of my projects, I use the brilliant Repeater Matrix module to set up dynamic content sections / blocks (this is not the focus of this tutorial, here's a detailed explanation). The module does have it's own built-in template file structure to render it's blocks, but since it won't work with my Twig setup, I'll create some custom twig templates for this. The approach will be the same as with the page template itself: create a "base" section template that includes some boilerplate HTML for recurring markup (such as a container element to wrap the section content in) and defines sections that can be overwritted by section-specific templates. First, let's create a template that will iterate over our the Repeater Matrix field (here it's called sections) and include the relevant template for each repeater matrix type:
      {# components/sections.twig #} {% for section in page.sections %} {% set template = 'sections/section--' ~ section.type ~ '.twig' %} {{ include( [template, 'sections/section.twig'], { section: section }, with_context = false ) }} {% endfor %} Note that the array syntax in the include function tells Twig to render the first template that exists. So for a section called downloads, it will look look for the template sections/section--downloads.twig and fallback to the generic sections/section.twig. The generic section template will only include the fields that are common to all sections. In my case, each section will have a headline (section_headline) and a select field to choose a background colour (section_background) :
      {# sections/section.twig #} {% set section_classes = [ 'section', section.type ? 'section--' ~ section.type, section.section_background.first.value ? 'section--' ~ section.section_background.first.value ] %} <div class="{{ section_classes|join(' ')|trim }}"> <section class="container"> {% block section_headline %} {% if section.section_headline %} <h2 class="section__headline">{{ section.section_headline }}</h2> {% endif %} {% endblock %} {% block section_content %} {{ section.type }} {% endblock %} </section> </div> This section template generates classes based on the section type and background colour (for example: section section--downloads section--green) so that I can add corresponding styling with CSS / SASS. The specific templates for each section will extend this base template and fill the block section_content with their custom markup. For example, for our downloads section (assuming it contains a multivalue files field download_files):
      {# sections/section--download.twig #} {% extends "sections/section.twig" %} {% block section_content %} <ul class="downloads"> {% for download in section.download_files %} <li class="downloads__row"> <a href="{{ download.file.url }}" download class="downloads__link"> {{ download.description ?: download.basename }} </a> </li> {% endfor %} </ul> {% endblock %} It took some setup, but now every section needs only care about their own unique fields and markup without having to include repetitive boilerplate markup. And it's still completely extensible: If you need, for example, a full-width block, you can just not extend the base section template and get a clean slate. Also, you can always go back to the base template and add more blocks as needed, without having to touch all the other sections. By the way, you can also extend the base section template from everywhere you want, not only from repeater matrix types.
      Now we only need to include the sections component inside the page template
      {# pages/page.twig #} {% block content %} {% if page.hasField('sections') and page.sections.count %} {{ include('components/sections.twig' }} {% endif %} {% endblock %} Conclusion
      This first part was mostly about a clean environment setup and template structure. By now you've probably got a good grasp on how I organize my twig templates into folders, depending on their role and importance:
      blocks: This contains reusable blocks that will be included many times, such as a responsive image block or a link block. components: This contains special regions such as the header and footer that will probably be only used once per page. sections: This will contain reusable, self-contained sections mostly based on the Repeater Matrix types. They may be used multiple times on one page. pages: High-level templates corresponding to ProcessWire templates. Those contain very little markup, but mostly include the appropriate components and sections. Depending on the size of the project, you could increase or decrease the granularity of this as needed, for example by grouping the sections into different subfolders. But it's a solid start for most medium-sized projects I tackle.
      Anyway, thanks for reading! I'll post the next part in a couple of days, where I will go over how to add more functionality into your environment in a scalable and reusable way. In the meantime, let me know how you would improve this setup!
×
×
  • Create New...