Translating API messages

no. there is no need for that in the api itself. you can translate those messages on the fly if you really want to show any api messages to a user. what should be done is that messages should be standardized and numbered, so you do not need regexping messages for different handlings..

if you ment api documentation, i think that is really not needed. we have google translate if someone who can programming really can't understand english.. that is mostly a waste of resources. api should be firstly be made fully usable. example things like adding updated_at to union-datastructure. and making that work like it should, also in profile-datastructure..

Translating what?
The keywords? - absolutely no. The labelling used in your own app can be translated.

The contents: No, - data entered by the users should remain unchanged, - however: If data is entered using multiple languages the API will give you all variants.

My question was about the keywords not the documentation.

The keywords is what it is: keywords" - binding the data together and should not be translated.

Some have made that fault in the translation model of Geni for some languages: Translated the keywords in the translation engine as well. For norwegian we decided early to lock those to English - those who does not understand English should stay away from translating English to Norwegian, and secondly that would also lock out Geni staff which does not understand English if we need some help.

Microsoft did a big mistake when they translated the commands in Excel...

Microsoft is sometimes forced by local law to translate their products.
Or make special local versions. An example is "Windows 10 China Government Edition",

But the diference between Microsoft and Geni.com is that the Geni.com staff only give support in English.

And Microsoft and MyHeritage give also support in other languages. MyHeritage does it in 19 languages. I can not find the number of languages Microsoft give support in.

Yes, true.

I still think Microsoft could have made the multi-language support in Excel iin a better way. A spreadsheet created in a English speaking country doesn't work if opened on a machine in Sweden and vice versa.
Commands could be translated for the user if underlying code was kept language-independent.
But I guess it might have been originally done some 30 years ago, so it might have historical reasons...