Translation was not working

[SIERRA]

Hi 

 Our simple code:

<?php
echo __("Welcome to our website");
?>

I have installed the following core modules:

1. Language Support
2. Language Support - Fields
3. Language Support - Page Names
4. Language Support - Tabs
5. Translation export/import

I added the translation text for both the default and Tamil languages for the sentence "Welcome to our website" in the admin interface.

Please find the screenshots PW-dash1.png and PW-dash2.png

However, we are facing an error when call this sentence in the following template file site/templates/test-lang.php.

Error: 
Fatal error: Uncaught Error: Call to undefined function __() in E:\wamp\www\processwire-dev\site\templates\test-lang.php on line 3
( ! ) Error: Call to undefined function __() in E:\wamp\www\processwire-dev\site\templates\test-lang.php on line 3

Please find the screenshot of PW-error.png

Please suggest how to resolve this.

Edited August 27 by SIERRA

[AndZyk]

Hi @SIERRA,

have you tried to declare the namespace at the beginning of your file?

<?php namespace ProcessWire;

echo __("Test");

I think it should work by adding the namespace.

I manually add the namespace on every file, although ProcessWire has a file compiler which should do this automatically.

Regards, Andreas

[SIERRA]

Hi,

Thank you. I added it at the beginning of the file, and now it works without errors.

However, translating to Tamil is not working; it remains in the default language.

Please find the screenshot of output and my code below.

<?php
namespace ProcessWire;

foreach($languages as $language) {
    if(!$page->viewable($language)) continue;
    echo "<a href='{$page->localUrl($language)}'>{$language->title}</a>";
    echo "<br>";
}

echo __("Welcome to our website");
?>

Can you please suggest a solution?

[da²]

You are actually viewing the site with default language. Try this:

user()->setLanguage("Tamil");
echo __("Welcome to our website");

 

[SIERRA]

Hi, @da²

user()->setLanguage("Tamil");

It is working.

We need to provide users with the option to change the language themselves

foreach($languages as $language) {
    if(!$page->viewable($language)) continue;
    echo "<a href='{$page->localUrl($language)}'>{$language->title}</a>";
}

The above code provides links to the languages, but after the page redirects, it shows the default language only.

Do you have any suggestions?

[da²]

If the user have an account: create a form with a select input listing languages, then set the selected language on current user and save.

$of = $user->of(false);

$user->language = $languages->getLanguage($form->language)->id;
$user->save();

$user->of($of);

$form->language is my select input, it's the language name.

 

If user has no account, it all depends on how you want to manage languages, common solution is to use language URLs, /de/, /fr/, /en/...
https://processwire.com/docs/multi-language-support/multi-language-urls/

Edited August 27 by da²

[SIERRA]

No, @da²

Not to specific user.

Guests have the option to change the language themselves.

How to fix this.

[da²]

I edited my previous message:

9 minutes ago, da² said:

it all depends on how you want to manage languages, common solution is to use language URLs, /de/, /fr/, /en/...
https://processwire.com/docs/multi-language-support/multi-language-urls/

[SIERRA]

When selecting Tamil, the page reloads and displays the default language again. No Tamil translation is happening.

Please suggest a solution.

 

[SIERRA]

Hi,

Can anyone please reply.

Thank you.

[poljpocket]

ProcessWire decides the language displayed based on the URL. I am assuming you didn't configure different root URLs for your languages and thus, ProcessWire doesn't know which language to display and will revert to the default language. A quick test shows this exact behaviour. If you configure your homepage URLs into something like this, your languages will work:

Edited August 28 by poljpocket
remove question, add answer after test

[AndZyk]

Hello @SIERRA,

in theory the translated string translation should be display, when visiting the translated page.
In your case "Welcome to our website" should be translated when visiting the "/test-language-tn/".

It is not necessary to manually switch the user language in the template file or to save it to a user, unless you want to build a different translations solution.

In your screenshot I cannot find the string translation "Welcome to our website". Can you please make a screenshot with the string?

Personally I don't use the core string translations anymore, instead I am using the ProField Functional Fields: https://processwire.com/blog/posts/functional-fields/
Because if you change the core string translation, all translations get lost and core string translations are not so nice for editors to edit.

Regards, Andreas

[poljpocket]

1 hour ago, AndZyk said:

Personally I don't use the core string translations anymore, instead I am using the ProField Functional Fields: https://processwire.com/blog/posts/functional-fields/
Because if you change the core string translation, all translations get lost and core string translations are not so nice for editors to edit.

Sorry for OT, but this isn't true. Maybe it is because the documentation lacks any mention of it, but years ago, @ryan fixed that problem in this commit:

Add support for retaining abandoned translations in `__('text')` call… · processwire/processwire@34cc4e9 (github.com)

You can pass an array with all alternates (as he calls them) to retain the old translations, e.g.:

<?php namespace ProcessWire;

$stillWorkingForOldTranslation = __(['new_translation_value', 'old_translation_value']);

Like this, you can update your strings and still carry over the old translations to apply to both the old and new versions of the strings.

I have to be honest, I believe this isn't generally known. I only know this because I stumbled upon this whilst reading the source code of the ProcessWire Core. This strategy also works for _x() and _n() functions, and also in modules with $this->__(), ->_x() and ->_n().

Edited August 28 by poljpocket

[AndZyk]

1 hour ago, poljpocket said:

You can pass an array with all alternates (as he calls them) to retain the old translations, e.g.:

Thank you for correcting me, I didn't knew about this option. I have been using Functional Fields since it was released, because of this and the nicer editor.

Good to know that this issue was fixed. 👍

[SIERRA]

4 hours ago, poljpocket said:

ProcessWire decides the language displayed based on the URL. I am assuming you didn't configure different root URLs for your languages and thus, ProcessWire doesn't know which language to display and will revert to the default language. A quick test shows this exact behaviour. If you configure your homepage URLs into something like this, your languages will work:

@poljpocket You are absolutely correct. 

After configuring the homepage URLs like you suggested.

Language translation is working fine.

Thanks for the help.

Thank you all.