directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <>
Subject Re: About I18n
Date Wed, 24 Mar 2010 19:46:25 GMT

On Mar 17, 2010, at 4:24 AM, Emmanuel Lecharny wrote:

> Hi guys,
> Felix has done a tremendous work extracting all the error messages  
> from the code and gathering them in a sub project (shared-i18n and  
> apacheds-i18n).
> This is just great, but I think we should go a bit further. If we  
> want to add a new error message, we have to add a new number at the  
> end of the list. As all the numbers start from 1 and are  
> incremented, it becomes rapidly difficult to group errors by their  
> numbers (ie, all the errors between 450 and 460 are related to  
> operation X).
> What about defining a number which would inform immediately about  
> the kind of message we are dealing with ? We can for instance use  
> hex numbers, where the two higher bits will be used to indicate the  
> log level :
> The idea is that if the number is <0, then it's an error or a warning.
> IN the same vein, we can also split the errors by family. As the  
> number will be an integer, it remains 30 bits to store informations.  
> Assuming that shared messages are indicated by the bit number 29,  
> then we have a way to split again :
> 101xxxxxx = a warning in the shared module
> 1111xxxxx = an error in the shared module, asn1 subproject...
> etc.
> wdyt ?

I have a fair bit of experience in this area and would recommend  
against using numbers.  It adds no value, one never needs to know the  
log level of a message when translating, and is an impediment to  
translation and understanding the code.  Here's an example that proves  
my point:

                 log.error( I18n.err( I18n.ERR_122 ), ioe );

That doesn't seem very helpful.  Would this not be better?

log.error( I18n.err( I18n.errorEncodingEncryptionKey ), ioe );

If I am reviewing/translating the i18n files

ERR_122=Störungskodierung EncryptionKey

is not as easy to read and fact check as

errorEncodingEncryptionKey=Störungskodierung EncryptionKey

Finally the set of static strings in the file are redundant  
and don't really add any safety per se.  As a matter of fact things  
become a bit more brittle and are morally equivalent to using ints  
instead of enums.  I might make these enums whose values become  
indexes to the resource bundle; this way you get type safety and can  
use your IDE to see who uses the message.

Just my 2 cents.


View raw message