dublindrupaller
commented
7 years ago 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.
kensoh
updated - feature implemented (more details at bottom of thread)
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.
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.