Hi Eike,
is it something you're working on? Otherwsise, can we turn it into an easyhack ?

It's a translation-only problem, nothing that can be worked on otherwise.
Translators will have to fix the malformed translations.

Created attachment 160011 [details]
SQL function names

SQL function names (msgctxt "RID_RSC_SQL_INTERNATIONAL") seems to suffer from the same issue, see e.g. bug 103736.

I generated this list with (in module translations; in one line)

git grep -A2 -F 'RID_RSC_SQL_INTERNATIONAL' |
egrep -B2 'msgstr ".*[^[:alnum:]_].*"'

This assumes [:alnum:] does the right thing in all languages / character sets.

Using the predefined character classes [:alpha:] and [:alnum:] may even be better, it catches things not thought of.. Though it depends on the current locale and delivers false positives in a C or non-UTF-8 locale.

On the other hand Calc allows some constructs like mid letter, spacing marks and modifier letters, I'll have to rethink the Calc grep.

FYI: added a check to weblate for the calc formula issues, using the matches erAck proposed:

in formula/messages.po for strings with context of RID_STRLIST_FUNCTION_NAMES:

Throw error if translation matches the regex [-+*/ ()~]
and throw error if one of source or translation starts with # but the other one doesn't.

Did use bulk change in weblate to flag all the strings as fuzzy, so while they'll still be present in the po file, they won't actually be used/treated as untranslated.

Please keep in mind that weblate is python based, so I'd need python re compatible expressions

Found out that translators had even more creative ideas.. and this catches more bad cases:
grep -E 'msgstr "(([^[:alpha:]])|(.*[-+*/&% ()~<=>!]))"'

However, python apparently doesn't know the predefined [:alpha:] class, so this could do as well:
'msgstr \"(([0-9_.].*)|(.*[-+*/&% ()~<=>!].*))\"'

If *only* the function name is to be matched, not the msgstr ..., then this is sufficient:
(^[0-9_.])|(.*[-+*/&% ()~<=>!])

(In reply to Lionel Elie Mamane from comment #6)
> 
> git grep -A2 -F 'RID_RSC_SQL_INTERNATIONAL' |
> egrep -B2 'msgstr ".*[^[:alnum:]_].*"'
> 
> This assumes [:alnum:] does the right thing in all languages / character
> sets.

Hmm. Please specify what "the right thing" is. I was assuming it should accept numerical and characters from all scripts, but the list also refuses combined characters, e.g. the গ্য that is a combination of গ + য (according to http://www.wbsed.gov.in/feedback/bengali_help.html, I have no idea of writing in that script :-))

Not treating combinations and advanced characters matches python's behaviour in regards to the \w character class, so I added a check for strings with context RID_RSC_SQL_INTERNATIONAL that complains unless the translation matches ^[\w\d]+$
(unicode word and digit characters, \w includes underscore)

Created attachment 179968 [details]
l10n-wrong-function-names-2.txt identifiers

Updated list from current master, 3 bad translations.

(In reply to Eike Rathke from comment #13)
> Created attachment 179968 [details]
> l10n-wrong-function-names-2.txt identifiers
> 
> Updated list from current master, 3 bad translations.

Fwiw, all 3 are _still_ present in current master after 2 years..
Affected is (only) the 'sd' "Sindhi, Devanagari" translation. Functionality / reparsing of table structured references in Calc is broken in that localization.

Created attachment 194869 [details]
l10n-wrong-function-names-1.txt function names

Updated list from current master, 263 bad function names translations.
Affected translations are:
am
bo
br
brx
da
dgo
dz
fa
gu
gug
kab
kmr-Latn
kok
ks
lb
lo
mai
mn
mni
my
nn
nr
rw
sa-IN
sat
sd
sid
tn
ts
ve
zu