From: SourceForge.net <no...@so...> - 2012-07-03 08:20:27
|
Feature Requests item #1182109, was opened at 2005-04-13 02:52 Message generated for change (Comment added) made by dkf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=360894&aid=1182109&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 6 Private: No Submitted By: Nicolas Castagne (nicolascastagne) Assigned to: Don Porter (dgp) Summary: Translate and manage error messages Initial Comment: Tcl is often used as a scripting language for users in big applications. However, users may not speak english - or, more generally, the language used in the app to communicate with the user may be not english. I suggest that Tcl should offer a way to handle error message in a better way, allowing : - at least translation of errors in other languages - better : machine-understandable description (such as error codes), so that the error message may be constructed according to the need, just before sending it to the user. For example, we CANNOT provide english error messages in our app. Given the current error management system, this seems to be quite a difficult problem to solve... Pointers for solutions : - split of error messages in various parts : static parts (such as "Syntax Error", etc.) and variable parts (which give details on the error, depending of the context : line number, name of the procedure, etc.). This is needed to set up a translation system by using msgcat, for example - generalisation of error codes. In the current version, error codes are not set for all the erros. For details : - see news://comp.lang.tcl : quite a large discussion took place on the subject, starting from April, 07, 2005, under the subjects " Managing (translate) errors in a different language " and "Translate error messages" - contact me ! ---------------------------------------------------------------------- >Comment By: Donal K. Fellows (dkf) Date: 2012-07-03 01:20 Message: 8.6 is much better about generating errorcodes correctly (as part of making [try] useful. ---------------------------------------------------------------------- Comment By: Nicolas Castagne (nicolascastagne) Date: 2005-09-30 08:11 Message: Logged In: YES user_id=1258423 See also 1309482 ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2005-04-18 07:56 Message: Logged In: YES user_id=80530 This question ties into idea about building $::errorInfo "lazily". See 523900 and 1047543. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2005-04-14 01:25 Message: Logged In: YES user_id=79902 Line numbers have already been split out separately (well, there's quite a bit of complexity in there; see TIP#90 for the details http://tip.tcl.tk/90) though it is often only a line number within a procedure definition for various reasons. I don't know if we put the containing command into the error dictionary yet. If not, it'd be a fine enhancement IMHO. Assigning to Don Porter for his comments on this side issue. ---------------------------------------------------------------------- Comment By: Nicolas Castagne (nicolascastagne) Date: 2005-04-13 09:14 Message: Logged In: YES user_id=1258423 Additional comment. Agree (I mean, a a Tcl user !) Then, in parallel with error code, other info describing the error should be recorded, such as : - line number (already available) - name of the unrecognized token - name of the proc in which the error took place - ... Dunno if it is easy to make a full overview of the info that should be recorded, so that a full error-message could be reconstructed by the caller of Tcl_Eval. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2005-04-13 03:34 Message: Logged In: YES user_id=79902 The correct approach is to update Tcl's internal error generation to make proper use of the errorCode facility so that we always have a machine-understandable representation of the error. Currently, we're horribly lax about this except for errors originating in the OS; most core errors are only described in human-readable terms in English. :^( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=360894&aid=1182109&group_id=10894 |