Weird behaviors with Processwire Site Translation Files / Code Internalization

[Orkun]

Hi Guys

I have a problem with the Code Internationalization (Site Translation Files) in Processwire. I am using the method Ryan is describing in this topic and also the normal way of translating files. The weird behaviors are that translations are just gone after a change in the main translation file called _strings (uses Ryan method). Or some other weird behavior was, that the english translation of the _strings file were somehow ported inside the german _strings file. I really don't know what could cause this. Have ever witnessed something like that? 

I have made some thoughts about this whole Code Internalization thing in ProcessWire and I am thinking to go another way (don't get me wrong, it's perfect for small to mid projects but in my opinion it is just a overkill for big projects), because at the beginning the strings we needed to translate were splitted up in many files which produced many site translation files to translate per language. It was just to much and confusing for the customer (and also for me), so that we needed another approach. So I tried Ryans method with one central translation files. The problem with this one is that it also gets confusing since it is a very big amount of strings to translate and also the problems described above. So for know I will try to make approach to store the strings in Pages. All translations of a string would be stored side by side. I know that this is probably more complex behind the scenes but it is far easier for the customer (especially with ListerPro). And I also like the idea of having the translations inside the DB instead in form of Files.

What are your thoughts about it? Have ever done something like that?

Greetings

Orkun

[Orkun]

I tried to make a function, which I can fetch translations from a page by it's name field.

Features of the function:

• Fetches translations from page title (multilanguage).
• Outputs an edit link to the Translation Page (doesn't output it when 2nd argument is false)
• When the translation page you are referencing is not found, it outputs an error and also the absolute path to the php file were the function was executed by using debug_backtrace function of PHP.

Benefits of this approach:

• You have full access to the ProcessWire API in terms of manipulating the translation data
• Translations of single Strings in different languages are side by side (tabs)
• Searching of single Translations is easy with Listers (I know search of site translation files is supported in PW3 but not in PW2, and I am using PW 2.7.3)
• Usability is far better since the users doesn't have to fiddle around in the system languages itself.

Possible disadvantages:

• Little overhead when using the function, since it always loads a page behind the scenes when the function is used. (I had used 8-13 function calls inside a template file and doesn't had noticed any performance issues (bless processwire)).

function _gt($key, $edit = TRUE){
    $link = "";
    $tracemessage = "";
    $string = "";

    $translationPage = wire('pages')->get("template=translation, name=$key");
    if($translationPage->id){
      if($edit && wire('user')->isLoggedin()){
        if(wire('user')->isSuperuser()){
          $editlink = " <a style='color:green;' target='_blank' href='".$translationPage->editUrl()."'>[Edit]</a>";
        } 
      } 
      $string = $translationPage->title.$editlink;
    }else{
      if(wire('user')->isLoggedin()){
        $trace = debug_backtrace();
        $tracemessage = "(".$trace[0]["file"].")";
      }
      $string = "<span style='color:white;background-color:red;padding:5px;'>[Not Found: '".$key."'] $tracemessage</span>";
    }

    return $string;
}

 

Example:

echo _gt("akkreditierung");
echo _gt("fachgebiete-doctor");

 

And when it fails to find the translation page:

Edited March 20, 2017 by Nukro
Function Rewrite, better explanation of use

[kixe]

I am quite happy with translation options included in PW.

Translatable strings like

$out = $this->_("Live long and prosper");  // syntax within a class (modules)
$out = __("Live long and prosper!"); // syntax outside of a class (templates)

are useful for modules and (rarely) in the template system.

To make them accesible globally I define a page property in my _init.php file which is prepended to each template.

/**
 * define globally used translatable strings here
 */
$page->__read_more = __('Read more');
$page->__submit = __('Submit');

 

Furthermore I use some language related functions (language specific date and time formats). These functions are placed in _func.inc which is included by the _init.php

// Include shared functions
include_once("_func.inc");

Everything else is content and should be stored in multilanguage fields. (text, textarea, optionselect)