I see that you are comparing Tokenscript with MoonLang, a domain specific language to build DApps instead of relying on a web application. It avoids the permission issue† and availability issue‡ and it addresses security in its own way.

† permission issue: someone who can call a smart contract but find it difficult to do so because the logic related to smart contract is on a web application that requires permission to use. e.g. a function returns an error but the error message is in a web application, or the eye colour of a cryptokitten is in a smart contract but the method to draw it is on a web application.

Tokenscript is signed and rely on the reputation of an organisation (often through a website). It aims to run more trust-worthy code than its environment. MoonLang is

Tokenscript is a mix of XML dialect and Javascript. MoonLang is a language.

Tokenscript is an infrastructure. MoonLang is a language, meaning Tokenscript cares about how it is used and MoonLang don't.

Regarding contract UI, it must not be in contracts, otherwise simple matter as adding a new language translation will lead to a contract update. A separate technology is preferable, in this case, Tokenscript, even if the UI elements (e.g. whether a book's copyright is expired, in the case of a book token) is carried out by 𝑝𝑢𝑟𝑒 Ethereum smart contract functions almost for the use of Tokenscript.