directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@gmail.com>
Subject Re: About I18n
Date Thu, 25 Mar 2010 07:03:46 GMT
Wow u just described fully and emaculated why this proposal was  
rubbing me the wrong way. I did not have the time to run through a use  
case to see clearly - thanks for doing this and commenting for all our  
benefit.

No general mechanical procedure makes up for act thought for each  
case. We have to watch for that here.

I agree with Alan on this one. Let's not further obfuscate our code.  
BTW it's time for a thorough audit of error messages and log output  
since these days many are complaining about false error and excessive  
verbosity without clear meaning.

Sent from my iPho

On Mar 24, 2010, at 9:46 PM, "Alan D. Cabrera" <list@toolazydogs.com>  
wrote:

>
> 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 :
>> DEBUG = 00XXXXXXXXX...
>> INFO  = 01XXXXXXXXX...
>> WARN  = 10XXXXXXXXX...
>> ERROR = 11XXXXXXXXX...
>>
>> 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 I18n.java 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.
>
>
> Regards,
> Alan
>

Mime
View raw message