That was planned in the beginning already. It is, however, not just a simple front-end change. Since we are talking about site names that just happen to be language names in the scope of Wikidata, the database would need to contain all the translations for each site name.
A more robust alternative would be to radically change the way sites are stored by having sites stored as entities.

Regarding the specifics of Wikidata, the translations could be hacked in using ULS, though that should definitely be done in form of a gadget and not be part of the Wikibase code. The problematic part would be to enrich the site selector widget to allow typing in the languages in the user's language.

• Bug 53022 has been marked as a duplicate of this bug. ***

(In reply to Henning from comment #1)

Regarding the specifics of Wikidata, the translations could be hacked in
using ULS, though that should definitely be done in form of a gadget and not
be part of the Wikibase code.

https://www.wikidata.org/wiki/User:Ricordisamoa/SitenamesInUserLanguage.js

(In reply to Ricordisamoa from comment #3)

https://www.wikidata.org/wiki/User:Ricordisamoa/SitenamesInUserLanguage.js

That is the easy part. :) It would be awesome to inject the language translations into the site selector widget in order to avoid inconsistency between displaying and entering sites. That would be the perfect Wikidata-specific gadget solution.

Regardless of that, I think storing sites as entities would be a great thing since site name translations could be provided via statements. But I guess that is some technical debt that will not resolve.

• This bug has been marked as a duplicate of bug 37703 ***