geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <Alex.Blew...@ioshq.com>
Subject Re: [i18n] Hardcoded message strings
Date Mon, 25 Aug 2003 16:04:48 GMT
On Monday, Aug 25, 2003, at 16:50 Europe/London, gianny DAMOUR wrote:

>> I also followed up a post on this to suggest that instead of package 
>> names, what about organising them by module name instead. Would this 
>> be better?
> Perhaps that structuring the messages via module is better.

Yes, and then you could have mail.i18n, web.i18n etc.

>> Can you explain what you mean a bit more by these points, and provide 
>> examples of what you're thinking? It's obviously late in the day (and 
>> I'm not allowed coffee at the moment) so I can't understand what you 
>> mean ...
>
> Quick overview of what I try to suggest:
>
> 1. A set of resource bundles defining the messages of specific 
> services, e.g. JavaMailMessages.properties; JCAMessages.properties; et 
> cetera.

Yes, I think (in general) it's better to have few i18n files than many 
i18n files, and one-per-module sounds like a good idea.

I don't think it makes sense for all of them to end in (only) 
.properties, because this may confuse a developer working with the 
module if it also needs configuration (e.g. JavaMail has several). 
However, I do accept that the Java i18n files will look for the 
.properties extension.

Can I suggest that we call them I18N-mail.properties, or 
mail-i18n.properties, so as to distinguish between the 
internationalisation and configuration aspects?

Alternatively, we could have resources/i18n/mail.properties, 
resources/i18n/web.properties etc. which would then all combine into 
the Jar with an i18n subdirectory.

> 2. A set of type-safe enumerations, one for each resource bundle, 
> which maps the keys of its related resource bundle to an element of 
> the type-safe enumeration.
>
> e.g.
>
> JavaMailMessage.properties defines the following messages:
> 00001=Authentication failed ${0} ${1}.
> 00002=Authentication failed#2.

Can you say why '00001' is better than 'authFailed'?

Can you also say why '00001' is better than 'mail.00001'? (assuming it 
is in the mail.properties, obviously ;-)

> One defines the following class:
> public final class JavaMailMessage {
>  private JavaMailMessage(int anErrorCode) {}
>  public JavaMailMessage FAILED = new JavaMailMessage(00001);
>  public JavaMailMessage FAILED_2 = new JavaMailMessage(00002);
> }

I don't see the advantage of:

public JavaMailMessage FAILED = new JavaMailMessage(00001); // NB this 
is an 'octal' number, and (00010) has the value 8, so be careful :-)

over

public String FAILED = "mail.authFailed";

> 3. A i18n exception specific to JavaMail.
> public I18NJavaMaiExceptionl extends I18NException {
>  public I18NJavaMailException(JavaMailMessage anException, Object[] 
> aListOfParameters) {};
> }

I don't think i18n needs to create a bunch of exceptions specific to 
i18n. Otherwise, for every Exception, you'll have an I18NXxxException, 
which sounds like a lot of work. Sometimes I think it would be useful, 
but not all the time.

> 4. An exception formatter specific to JavaMail.
> public I18NJavaMailExceptionFormatter extends I18NExceptionFormatter {
>  private I18NJavaMailExceptionFormatter SINGLETON = new 
> I18NJavaMailExceptionFormatter();
>  public I18NJavaMailExceptionFormatter getInstance() {};
>  public String format(I18NJavaMaiException) {};
> }

Would we need this over and above a normal formatter? Presumably we can 
work this into the logging messaging system?

> 5. In the code, one uses this:
> throw new I18NJavaMailException(JavaMailMessage.FAILED, new Object[] 
> {"value1", "value2"});

I agree in general wtih this idea of having an I18N exception type and 
an array of objects for the values, but don't necessarily see why this 
needs to occur for each XxxException. Why not just have the superclass?

Alex.


Mime
View raw message