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

[Dave Shields <shields@xxxxxxxxxxxxxx>]

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
-- 
Dave Shields, IBM Research, shields@xxxxxxxxxxxxxx.