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.
