[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Mar 31 00:20:24 2000 
Subject:Language dependent error messages (Was from Jonathan Cunningham about Macintosh implementations) 
From:Aaron Sloman See text for reply address 
Volume-ID:1000331.03 

Jonathan Cunningham jlc@sofluc.co.uk writes:

> Date: 30 Mar 2000 15:18:36 GMT
>
> (Another opportunity to test your mail gateway ;-)

Now working apparently.

[JLC]
> The following is actually a more general point, which is
> still relevant to poplog now.
> ...
[AS]
> >We discussed moving all those hundreds of strings out into a file,
> >with numbers or labels and having an error mechanism which found the
> >appropriate string when an error occurred. We decided against that
>
[JLC]
> There is another advantage to removing error messages from the
> source code ... internationalisation.
>
> In developing a C++ application, modern tools make this relatively
> simple to do. (The strings aren't stored in a file, but in
> a "string table".)
>
> Why? So it is very easy to produce different national versions of
> the product. You don't need multiple versions of the source; just                   
> link with a different string table. (Actually, in a graphical UI
> you may need also to take into account the length of the strings.)                   
>
> This is not so important for something like poplog as it would be
> for a consumer product but even so, just conceivably, people might
> like to get messages in their own language.

Yes.

The tools supporting this for developers of a system as large and
complex would have to be able to work with teams of programmers
simultaneously working on different parts of the system, perhaps
with some of them working on some files on machines at home and then
bringing them in to the office to install them.

You'd either need a tool that's guaranteed to give you a unique
error label wherever you are doing your work (e.g. something based
on your name or a code assigned to each programmer, or a label
fetched from an `error label server' across the internet), or the
labels would have to be generated when the files are installed into
the master system, or possibly when they are first compiled.

> ...
> But, nowadays, I still wouldn't use error codes.

I assume you mean by that that you would not have error codes
printed out at run time. I agree. I assumed that when errors
occured the label or number would be used by the run-time system
to fetch a string to print, perhaps using a new procedure

    string_for_code(code, current_language)

> Instead, I would
> redefine prmishap to look up the error string in a separate
> table. This table could be in an ordinary library, and loaded in
> the usual way, at startup.

yes. or possibly when the first error occurs!

> This is so obvious, I wonder if it has already been done?

Probably for many multi-language systems.

Aaron
===