Write and run automation flows in different human languages

updated - feature implemented (more details at bottom of thread)

• iteration 1 - simple search and replace matches of language strings
• iteration 2 - TagUI steps and syntax model to reduce false positives
• iteration 3 - translation for helper functions title(), text(), present() etc
• iteration 4 - automation steps execution output in different languages
• iteration 5 - working engine with 21 languages (mostly automatically built)

The languages are Bengali, Chinese, English, French, German, Hindi, Hungarian, Indonesian, Italian, Japanese, Korean, Polish, Portuguese, Romanian, Russian, Serbian, Spanish, Tagalog, Tamil, Thai, Vietnamese. A user can easily automate building a new native language definition by using this TagUI automation flow that builds the vocabulary set using Google Translate.

This starting set is partly chosen base on the list of most commonly used languages, partly from the countries around where I’m from (Singapore), and partly countries with a lot of developers.

---

This is purely an experimental idea. Since TagUI steps and conditions are in natural-language-like syntax, it might be easily extendable to support ‘natural language’ in other languages besides English. For example, Chinese (which I’m a native speaker), and Hindi (which there are many talents in test automation and robotic processx automation).

The hard way to do this is to rewrite the code for each step and condition to factor in different languages. But that is tedious -> hard to update or extend to other new languages.

An easy way is to use English as the internal reference and try to minimize changes to existing codebase. Then create a translation engine which takes in configuration files (.csv files for example), that translates from another language into the English reference language before execution. That engine can also be used to translate flow files between different languages, from Chinese to Hindi for example. Or English to Chinese.

If the design is flexible enough, users can easily create their own language configuration csv files for their native language. And write automation flow files directly in their native language. There will be implementation issues no doubt, but this hyper-localization idea is too interesting not to try.

Below is quick sanity test on macOS, looks like no apparent technical roadblock to the idea -> comparing and displaying strings in other languages works correctly. The flow files also shows text correctly in the other languages.

START - automation started - Thu Nov 09 2017 15:16:47 GMT+0800 (+08)
http://tebel.org/index_mobile.php - Tebel.Automation

点击
WORKS!

http://tebel.org/index_mobile.php - Tebel.Automation
FINISH - automation finished - 2.9s

START - automation started - Thu Nov 09 2017 15:19:05 GMT+0800 (+08)
http://tebel.org/index_mobile.php - Tebel.Automation

क्लिक
WORKS!

http://tebel.org/index_mobile.php - Tebel.Automation
FINISH - automation finished - 2.1s

The integration with machine learning (starting with Yandex CatBoost) is important. But this idea is equally if not more important imo. Probably this can be developed concurrently with ML for TagUI v3.0.

[dublindrupaller]

Can I suggest you look at how .po or .pot files are used instead of .csv as a possible alternative? it’s, pretty much, a standard for storing multilingual strings for applications and there are lots of open source editors available.

the advantage is you can, long term, handle ALL text strings, steps/intents, debug messages etc, in multiple languages within your application and it is simple for non-devs to tweak the languages.

I’ve worked on projects in 80+ languages, including arabic, korean, hebrew, russian etc. as well as the standard european and it is not difficult to rejig your parsing logic based on a base language key ( using the ISO 639-1 Code) e.g. en for english, ar for arabic to handle right-to-left.

in simple PHP logic, it might look something like this:

switch ($base_lang) {
  case "en":
  // load en.po file
  //base language is english, so handle step intent left-to-right
  break;
 case "ar":
  // load ar.po file
  // base language is arabic, so handle intent right-to-left
  break;
}

[dublindrupaller]

hi kensoh,

I have been looking at the same with my fork of tagui. I’m in Switzerland, where there are mainly 4 languages used…swiss-german, french, italian and English.

Using the php classes, we can use out-of-the-box aliases. Using the tap.class.php file as an example, you have the following.

`
/**
 * @file
 *
 */

/**
 *  tap class which is a child of step
 *  The class contains three methods:
 *  - public getIntent()
 *  - public parseIntent()
 *  - public get_header_js() 
 */

class tap extends step {
      
  /**
   * Construct wrapper object   
   */
  public function __construct($intent){    
    $this->intent = $intent;
  }
  /**
   * @return string
   */
  public function getIntent($intent) {    

    if ((substr($intent,0,4)=="tap ") || (substr($intent,0,6)=="click ")) {
      return $this->intent;
    }    
    return FALSE;
  }

  /**
   * @return string 
   *   casperjs code as string
   *
   * @param string $raw_intent
   *   The full written step line for passing directly to the casperjs output or parsing for sikuli
   * @param array $params
   *   Array of params for the given step
   * @param string $twb
   *   Tagui_web_browser token for constructing test header casperjs   
   * @param boolean $sikuli
   *   if input is meant for sikuli visual automation 
   *
   */
  public function parseIntent($intent, $raw_intent, $twb, $sikuli=FALSE) {     

  $params = trim(substr($raw_intent." ",1+strpos($raw_intent." "," ")));
  // TODO: $params is passed as an array but sent to casperjs code and sikuli output as a string   
    if ($sikuli) {
      $abs_params = abs_file($params); 
      $abs_intent = str_replace($params,$abs_params,$raw_intent);
      $parsed_code =  call_sikuli($abs_intent,$abs_params);
    } else {
      $parsed_code = "{techo('".$raw_intent."');".beg_tx($params).$twb.".click(tx('" . $params . "'));".end_tx($params);       
    }    
    return $parsed_code;
  } 

  public function getHeaderJs() {
    $js = <<<TAGUI
function tap_intent(raw_intent) {
var params = ((raw_intent + ' ').substr(1+(raw_intent + ' ').indexOf(' '))).trim();
if (is_sikuli(params)) {var abs_params = abs_file(params); var abs_intent = raw_intent.replace(params,abs_params);
return call_sikuli(abs_intent,abs_params);} 
if (params == '') return "this.echo('ERROR - target missing for " + raw_intent + "')";
else if (check_tx(params)) return "this.click(tx('" + params + "'))";
else return "this.echo('ERROR - cannot find " + params + "')";}
TAGUI;
    return $js;
  }       
}
class_alias('tap', 'click');
`

By simply extending the class_alias, you can have:

class_alias('tap', 'click', 'cliquez', 'klicken', 'cliceail', 'clic');

Where: “Cliquez” is the french for click “klicken” is the german for click “cliceail” is the Irish (gaelic) for click - as an aside, I am Irish :0) and “clic” is the Italian for click

Obviously that is scalable for other languages and logic can be added to handle the operators for some other steps. But the concept is simple enough.