Best practice for static string translations

[a-ok]

I’m sure there was a PW Weekly or blog post recently about best practice for static word translations in your code for multi-language sites (for things like ‘Read more’ or ‘Submit’ etc) but I cannot find it anywhere...

Have I made this up?

[rafaoski]

Hi ... Here you should find a lot about the translations

https://processwire.com/api/multi-language-support/code-i18n/

I do not know if this is the best solution, but it works for me ...

Thanks to this, I do not have to search for translations in all of the template's peaks ...

So I create a simple file responsible for all translations

_translate.php

Include this file inside _init.php

include_once('./_func.php');

include_once('./_translate.php');

And define in the table as below
 

<?php namespace ProcessWire;
// Translate Strings
page()->ts = [

// Language => locale / code prefx
'locale' => _x('en_US', 'HTML locale code'),
'lang_code' => _x('en', 'HTML language code'),

// Main Page ( main.php )
'site_name' => __('Your Site Name'),
'logo_alt' => __('Show My Awesome Logo'),

// Archives Page
's_archives' => __('Select The Archives'),
'date' => __('Date'),
];

Then you can call globally using page()

<h1><?=page()->ts['site_name'];?></h1>

And there is a pro option Functional Fields:

https://processwire.com/blog/posts/functional-fields/

But I can not say too much about it because I have not tested it but it looks interesting ?

Edited August 30, 2018 by rafaoski
Update

[a-ok]

Thanks for your reply @rafaoski – much appreciated.

I guess if I wanted the client to update this the only way would be CMS fields, right?

EDIT:

I had a look at Functional Fields (and this is what I remembered reading about) but I cannot see the benefit of just creating a normal text field, especially if you have to create a field anyway? Probably missing the point entirely.

Edited August 30, 2018 by oma

[dragan]

28 minutes ago, oma said:

I had a look at Functional Fields (and this is what I remembered reading about) but I cannot see the benefit of just creating a normal text field, especially if you have to create a field anyway? Probably missing the point entirely.

I'm afraid you do ?

What you do, is define all the strings in one template. Then create a page with said template, and you'll see that for each string PW creates input fields. The name "Functional Fields" is perhaps a bit misleading. PW doesn't create a field for each string. I'll post some screenshots / code examples a bit later...

[rafaoski]

If you want the customer to easily update the fields you can create a translate and translate_string templates.

You will be able to easily create translations using pages ...

Next, create function inside the _translate file to show translateable field title as in the movie, for example:

<?php namespace ProcessWire;

function trStr($page, $str) {

$tr_page = pages()->get("/translate/$page/")->title;

if($tr_page) {

    return $tr_page;

} else {

    return $str;

}

}

// Translate Strings
page()->ts = [

'your_awesome_string' => trStr('your-awesome-string', __('Your Awesome Strings')),

];

And display on the site:

<h1><?=page()->ts['your_awesome_string']?></h1>

 

You can download this profile from here: 

 

[dragan]

OK, so as promised, for a use-case with Functional Fields, here's a simple code example and a screenshot how it might look like in the backend:

__fieldset('plain,textarea,rich,hello', 'jsStrings', 'Javascript Strings');

// $pages->get(1044)->functional->plain // how you would get it from anywhere in your templates and pages
echo "<p>" . __text('your plain text', 'plain', 'Label Text for Plain Text String') . "</p>";

// $pages->get(1044)->functional->textarea // how you would get it from anywhere in your templates and pages
echo "<p>" . nl2br(__textarea('your textarea text', 'textarea', 'Label Text for Textarea')) . "</p>";

// $pages->get(1044)->functional->rich // how you would get it from anywhere in your templates and pages
echo "<div>" . __richtext('<p>your richtext</p>', 'rich', 'Label for WYSIWYG') . "</div>";
echo "<div>" . __richtext('<p>Hello Wörld!!!</p>', 'hello', 'Label for Hello World') . "</div>";

 

This is how it looks like in the backend. The big advantage imho is that you have the familiar user interface you're used to when you are also in charge of creating or editing PW-pages. It all seems familiar, and if you have a multi-lang setup, you can edit it all without page-reloads and navigating to another language.

[OLSA]

Hi,

this is one of examples how can be used ConfigurationForm module.

1. Create field "translate", fieldtype ConfigurationForm Fieldtype

2. In field setup create desired fields what would store translations (eg. textLanguage fields: readmore and submit, and  textareaLanguage fields error and success)

Please note how to setup these fields:

There is no image for success field setup, but it is the same like for the "error note" (textarea, type: textareaLanguage, name: success).

3. In Actions tab, add "translate" field to desired template (eg. Home).

4. Press ProcessWire Save button (ignore blue Save button).

5. After, on Homepage, you will get this:

6. Write desired translations, please note to language switcher on inputfields right side.

Press page Save button.

How to render translations?

1. call field->subfield and echo it (subfield name).

<?php

// get main field (container where are all translations)
// our translations are on Homepage

$translate = $pages->get(1)->translate;

//Submit
echo $translate->submit;

// Read more
echo $translate->readmore

// etc...
?>

With this you can get elegant solution to store all needed translations, easy to add new and easy to administrate. Also if someone forget to write some translation, output would be default translation content.

Regards.

[adrian]

Some great examples here already and these are probably the best approach, but just another alternative (in case it's useful) is to use a Profields Table field - this way you can easily define a new string to translate as a new row in the table.

[Krlos]

On 8/30/2018 at 7:38 PM, adrian said:

Some great examples here already and these are probably the best approach, but just another alternative (in case it's useful) is to use a Profields Table field - this way you can easily define a new string to translate as a new row in the table.

Hi @adrian,

Can you please elaborate your answer a little further, I have never used Profields Table field, and I have some doubts about how to use it for translations.

Thank you.