Internationalization for mathjs (e.g., error message translation)

[strivezsh]

function undef (name) {
throw new Error('Undefined symbol ' + name)
}

function undef (name) {
throw new Error('未匹配到对应参数 ' + name)
}

[josdejong]

That would be nice indeed, thanks for your suggestion. Anyone interested in picking this up?

[gwhitney]

Sorry, the proposal here is unclear to me: Isn't the question of whether an Error string can contain Unicode a JavaScript question, not particularly a mathjs question? Or is there some error facility in mathjs that does not currently allow Unicode strings? If so, a clearer way to demonstrate the current limitation would be helpful.

[tmtron]

For me the issue is that we cannot easily translate the errors into another language. E.g. when we have a web-server that does some calculation for a user and something goes wrong, we want to send an e-mail to the user and this should contain the error-messsage in the correct language for the user: e.g. English, German or French.

In the current version of MathJs this is tricky.
e.g. when MathJs throws an undefined symbol error, as mentioned in the OP's example:

mathjs/src/expression/node/SymbolNode.js

Lines 108 to 110 in 3c59063

	static onUndefinedSymbol (name) {
	throw new Error('Undefined symbol ' + name)
	}

we only get a string, like 'Undefined symbol MyVar'. It would be tricky to translate this, because we must first parse the text to find the name of the symbol. And if the error-text in the library changes, it may break our parsing logic.

There are different ways that this could be solved.
e.g. you could attach additional details to the Error that you throw, like a unique Identifier (e.g. enum: MathJsError.UndefinedSymbol) and additional JSON for the variable parts: { symbolName: "MyVar"}
Then the users of the library have all the required information to easily build a localised error-message.

Another way is to use a hierarchy of error-classes. e.g. all errors, that you throw should be child-classes of MathJsError. For the UndefinedSymbol case, you could use something like

class UndefinedSymbolError extends MathJsError {
    constructor(public symbolName: string) {
        super('Undefined symbol ' + symbolName);
    }
}

Then the users of the library can simply check if the error is an instance of UndefinedSymbolError and access the additional data (symbolName) in a type-safe manner.

[gwhitney]

OK. As you probably know, in the specific case of undefined symbol and undefined function errors, you can simply redefine math.SymbolNode.onUndefinedSymbol or math.SymbolNode.onUndefinedFunction on the fly, e.g.

math.SymbolNode.onUndefinedSymbol = name => {
    throw new Error('Why are you asking me about ' + name)
}
const val = math.evaluate('37+a')
console.log('Got', val)

crashes with a Why are you asking me about a message.

But your point is well taken, that there are numerous errors and potentially other messages generated by mathjs, and it would be good to either (a) have a structure which better supports ad-hoc internationalization by clients as you describe in this post, or (b) truly integrated internationalization with shipping language addons. That's a larger Discussion, so retitling this accordingly and moving to Discussions.

[gwhitney]

What other messages and strings besides error messages need internationalization? I think a wholesale suite of translations of the entire online documentation is out of scope, but certainly the results of the internal help function should be translated. The function symbols are mostly standard mathematical notations and should remain fixed, but what about the non-mathematical facilities like help, compile, evaluate, parse, etc. -- should they have internationalized aliases? Are there other messages/strings I am not thinking of?