RE: [stellation-res] Progress report on symbolized strings and i18n rela

["Jonathan Gossage" <jgossage@xxxxxxxx>]

> >-----Original Message-----
> >From: stellation-res-admin@xxxxxxxxxxxxxxx
> >[mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Dave Shields
> >Sent: September 10, 2002 5:16 PM
> >To: Stellation
> >Subject: Re: [stellation-res] Progress report on symbolized strings and
> >i18n related string issues
> >
> >
> >On Sun, Sep 08, 2002 at 09:34:16PM -0400, Jonathan Gossage wrote:
> >> I have made a pass over a part of the org.eclipse.stellation.workspace
> >> package identifying all strings that can be affected by either
> >commonality
> >> or language translation issues. The procedures I have come up
> >with make use
> >> of the Eclipse Externalize Strings Wizard and a good deal of
> >hand coding. I
> >> can now handle the following situations in a reasonable manner.
> >>
> >
> >Jonathan,
> >
> >Thanks for taking the time to investigate this so carefully. However,
> >I find the propsed internationalization code much too heavyweight. For
> >example, in workspace Svc.java
> >
> >    public StringMap defaultOptionValues() {
> >        return
> >            new StringMap()
> >            .add("debug","")
> >            .add("options","")
> >            .add("project","")
> >            .add("username", System.getProperty("user.name"))
> >            .add("verbose","")
> >            .add("comment", "-");
> >    }
> >
> >becomes
> >
> >    public StringMap defaultOptionValues() {
> >        return
> >            new StringMap()
> >            .add(Ws.getString(Ws.optionDebug()),
> >                 "") //$NON-NLS-1$
> >            .add(Ws.getString(Ws.optionOptions()),
> >                 "") //$NON-NLS-1$
> >            .add(Ws.getString(Ws.optionProject()),
> >                 "") //$NON-NLS-1$
> >            .add(Ws.getString(Ws.optionUsername()),
> >                 System.getProperty("user.name")) //$NON-NLS-1$
> >            .add(Ws.getString(Ws.optionVerbose()),
> >                 "") //$NON-NLS-1$
> >            .add(Ws.getString(Ws.optionComment()),
> >                 "-"); //$NON-NLS-1$
> >    }
> >
> >The problem is that in the new scheme virtually every string literal
> >becomes a method call, making the code harder to read and harder to
> >work with, thus raising the barrier to entry yet higher.
> >
> >I would suggest tabling this effort for now, as I doubt all developers
> >will be willing to assume the extra burden this scheme would impose.
> >
> >Perhaps we could try something more lightweight, just concentrating on
> >command names, option names, and message strings, though I venture
> >even this might be too much trouble until the code is in more stable
> >form and there is a convincing need to provide multi-language support.
> >
> >dave
> >--

That's why I wanted everyone to see this. I agree that in the absence of
really good tools that this is a very high maintenance exercise.

Regards

Jonathan

Personal Email
jgossage@xxxxxxxx

Business Email
jonathan@xxxxxxxxxxxxx