In latest In-Portal 5.1.2, I have came across a small bug (on Front-End) in sorting drop-down for Multilingual fields. Try sorting your Links by Name A-Z and then Name Z-A. The actual sorting works well, but the drop-down which shows the direction is not due to some minor bug.
The problem is that method is used by AddOrderField and SortingSelected methods where 1st is used to be put in SQL when 2nd to be used in the tag processor.
$table_name = '`' . $this->TableName . '`';
$lang = $this->Application->GetVar('m_lang');
$primary_lang = $this->Application->GetDefaultLanguageId();
$ret = 'IF(COALESCE(%1$s.l' . $lang . '_' . $field . ', ""), %1$s.l' . $lang . '_' . $field . ', %1$s.l' . $primary_lang . '_' . $field . ')';
return sprintf($ret, $table_name);
It breaks due to $ret = 'IF(COALESCE(%1$s.l' . $lang . '_' . $field . ', ""), %1$s.l' . $lang . '_' . $field . ', %1$s.l' . $primary_lang . '_' . $field . ')'; part when it's getting passed to SortingSelected for comparison.
I guess it brings up the question whether we really should count in the Language Prefix for in SortingSelected($params), but instead just work with it as Name|desc and Description|desc without trying to match l1_Name|desc = l1_Name|desc in the check for Multilingual fields? Like here:
return strtolower($current_sorting) == strtolower($params['sorting']) ? $params['selected'] : '';
I have attached a simple patch which might not be the optimal solution, but has been tested by me well.
Alex what you think?