Re: [Openinteract-dev] Generic way to translate error messages

[Chris W. <ch...@cw...>]

On Mon, 2002-03-18 at 09:08, Perrin Harkins wrote:
> The usual way to do it is to use constants, so you can say something 
> like $INVALID_EMAIL_ADDRESS instead of 15387.  You could even use a name 
> like that as the error's ID instead of a number.

I'm ambivalent about using a name as an error ID. It's generally easier
to remember than a code but you'd almost certainly have to look it up
anyway to find the exact phrasing. So why not make it succinct? Using
constants as you suggest allows you to do both, so that sounds good to
me. 

> Is it really necessary to use a database for this?  It seems like this 
> would be a read-only file in production.  I think this could be done 
> with a simple file structure, which would make it easy enough to edit by 
> hand (while still allowing tools to be built) and avoid the performance 
> issues.
> 
> Things like this straddle the line between templates and data.  In 
> general, I like to put things on the file system when possible so that 
> they're easy to get at.

In general, I agree with you. And for file structures we already have a
format defined in Apache::Language, although I've never used that so I
don't know how successful it is. To be more explicit about my
motivations for using a database (thinking out loud here):

1. We already have mature tools to manipulate objects in a database.
(OTOH, if the messages are SPOPS objects, we don't really care where/how
they're stored.)

2. Keeping data in one place is a Good Thing for backup/restore
procedures, etc.

3. While error messages will rarely (if ever) be modified once they're
loaded, other localization messages almost certainly will be modified
more frequently and I hope to be able to use the same tools to do this.

4. Keeping a centralized store of messages makes it easier to ensure the
message are consistent across multiple servers 

Performance may be an issue, but I think (hope?) caching the messages on
demand will take care of that.

The ease of editing a file is something this system lacks. To
accommodate future use of files we'll probably have to either create an
import process to bring file contents into a database or create an open
interface so you can use either the database or the filesystem. I'd
rather do the former (it's easier) but can easily remain open for the
latter.

Chris

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.