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

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

On Mon, 2002-03-18 at 04:43, Magnus Espeland wrote:
> I'm developing for norwegian speaking users and need to make the sites in
> norwegian, but I see error messages and other small messages like this in
> the source code (from base_user::NewUser.pm):
> 
> my $error_msg = 'Could not create user in database. Error has ' .
> 		'been logged and administrator contacted.';
> 
> I was thinking, can we do something like this:
> 
> my $error_msg = OpenInteract::Translate->error('msg' => 'Could not create
> 						user ?1?, because ?2?',
> 						'1' => "$username",
> 						'2' => "$foo");
> 
> (you probably want to change class/method name and tokens, but that's
> another matter;-)

Error messages and handling has always been a sticky issue. What's in OI
right now is a little clunky and, as you found out, is impossible to
extend in any meaningful way.

I think what you've specified here is a start. But using the message in
the method call gives people the impression they can change it and the
translation will still work.

What many systems do is use error codes to specify the message to
display and allow variable substitution similar to what you've
specified. So we could create something like:

 my $msg = OpenInteract::Translate->error( 15789, $username, $foo );

Or even create a shortcut:

 use OpenInteract::Translate qw( error_message );
 ...
 my $msg = error_message 15789, $username, $foo;

The message would be pulled from a table based on the user's language,
or fall through to english if none is specified for the user's language.

The only problem with this is using an error code -- it doesn't
immediately *feel* right to me. But I don't really see any way around
this -- this is how standard libraries like GNU gettext work. So I
assume that after some usage it begins to feel more appropriate :-)

> The error method simply substitutes ?1? with $username and ?2? with $foo
> and falls thru if the user wants english. If not it replaces it with the
> translated version, like this:
>
> 1.First check if it's cached in the module
> I reckon we could save some db hits this way. Maybe we'll have to limit
> the cache size though, so we don't eat too much. Maybe we should do some
> cache ageing too?

We'd probably want to cache as much as possible. The web interface
should signal the cache to expire only the items being edited, otherwise
since these change fairly rarely we should have a very long-lived cache
for this.

> 2.If it's not in the module, check the database
> See my proposed db layout bellow. Maybe we should do it in a file instead?
> I feel like db, but don't know why;-) Add the translation to the cache in
> the module.

Using a database makes things easier for us -- no file locking issues,
etc. -- so we'll almost certainly stick to it. I have some potential
changes below.

> 3.If it's not in the database, add it
> If we can't find it, we add the english version to the db and tell an
> admin, (s)he will then see an untranslated line in the webinterface. This
> way all new erros in new versions of a package gets added, and we can
> translate as they come. The idea is to make it flexible...

Flexible is good.

> 4.Use english as backup language
> We already have the original message, so we can use that. Maybe some
> people would prefer a backup response in their language instead.

Yes, this should be modifiable from the server configuration.

> What I think we need/issues:
> 
> - Webinterface, to use for translating and uploading already translated
> errors (in a file)

Yes.

> - A way to share tranlations easy 

Yes, excellent idea.

> - It should be very little extra work for developers, maybe my proposed
> syntax is a bit too long?

Comments above.

> - Timestamp error messages, so that messages in old packages we don't use
> anymore can be discarded

Well, this probably isn't necessary if we use a database.

> - Larger language field in the sys_user table, we have 4 languages in
> Norway.. (Only two in popular use though)

I confess ignorance to these sorts of issues. I had thought the standard
language markers were two characters, but now I see there are also five
character versions (e.g., 'en-br'). Do you know if this is the largest
they get?

> Proposed db layout:
> 
> CREATE TABLE error_msg {
> 	error_msg_id	%%INCREMENT%%,
> 	error_msg	text,
> 	last_used	timestamp,
> 	primary key	(error_msg_id)
> };
> 
> CREATE TABLE error_msg_translated {
> 	error_msg_id	%%INCREMENT_TYPE%%,
> 	language	char(4),
> 	error_msg	text,
> 	primary key	(error_msg_id,language)
> };

With the ideas I mentioned above, we might use something like:

CREATE TABLE sys_error_message (
      error_msg_id     %%INCREMENT%%,
      error_code       varchar(8) not null
      language         varchar(5) not null,
      message          varchar(255),
      primary key( error_msg_id ),
      unique( error_code, language )
)

For tracking error_codes, we might also have:

CREATE TABLE sys_error_code (
      error_code      varchar(8) not null,
      error_type      varchar(150) not null,
      package         varchar(30) null,
      primary key( error_code )
)

This way you can easily create a report of all error codes in the system
for reference purposes. The 'package' field is so you can tell which
package created the original error message.

Both our schemes would also make it fairly simple to create 'message
balls', or distributable bundles of error messages. I've already done
something similar to this for distributing themes ('theme balls') in the
next version of OI.

> I haven't started coding this yet, I would like your feedback first...
> 
> Chris: How would you like me to make patches for you, if you want to
> add it in the offical code? (I've never made a patch before ;-)

We'd definitely add this to the base_error package. What do you think
about the error code idea?

Another thing to consider: back at the beginning of October on the -dev
list, Jochen Lillich and I had a more generic discussion about
localization in templates. But I have not been able to work on this yet
for the next version of OI. I don't know if these ideas should
necessarily be merged, but we might want to think about it. I actually
have some ideas on how they might be merged, but this email is getting
quite long.... :-)

Later,

Chris

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