Return-Path: Delivered-To: apmail-incubator-geronimo-dev-archive@incubator.apache.org Received: (qmail 63403 invoked by uid 500); 26 Aug 2003 17:45:40 -0000 Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: geronimo-dev@incubator.apache.org Delivered-To: mailing list geronimo-dev@incubator.apache.org Received: (qmail 63296 invoked from network); 26 Aug 2003 17:45:38 -0000 Received: from unknown (HELO smtp017.mail.yahoo.com) (216.136.174.114) by daedalus.apache.org with SMTP; 26 Aug 2003 17:45:38 -0000 Received: from unknown (HELO yahoo.co.uk) (james?strachan@217.204.102.101 with plain) by smtp.mail.vip.sc5.yahoo.com with SMTP; 26 Aug 2003 17:45:33 -0000 Date: Tue, 26 Aug 2003 18:45:21 +0100 Subject: Re: [i18n] Hardcoded message strings Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: James Strachan To: geronimo-dev@incubator.apache.org Content-Transfer-Encoding: 7bit In-Reply-To: <830FE324-D7EB-11D7-9B9F-000393DB559A@coredevelopers.net> Message-Id: <107DC847-D7ED-11D7-8A8C-000A959D0312@yahoo.co.uk> X-Mailer: Apple Mail (2.552) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Agreed with all that. My only comment is - lets try put all the messages inside the exception classes. So that in Java code we throw the exception which accurately describes what the exception is... e.g. throw new InsertOfEntityBeanFailedException(bean, sqlException, errorCode); and there's no message / text in the throws clause. Then we can refactor later to make the getLocalizedMessage() support i18n without affecting the codebase much. This also allows for fine grained exception catching too. On Tuesday, August 26, 2003, at 06:34 pm, Dain Sundstrom wrote: > Again we have the cart way ahead of the horse... > > We need to draw a line. What are we gong to make i18 and what are we > going to leave in english. When are we going to add i18? > > I suggest we come up with a way for us to add i18 later without any > pain now (see my previous message). Further, I suggest we make the > rule that only user displayable messages and log messages > info > support i18, but now Exceptions, debug, or trace. > > We have a huge project in front of us and we should do everything to > make this a fast and enjoyable experience, and I find that editing > messages bundles and working with message formatter to be neither. I > think we should take a long breath and think about a way to make it > easy add this later. > > -dain > > /************************* > * Dain Sundstrom > * Partner > * Core Developers Network > *************************/ > > James ------- http://radio.weblogs.com/0112098/