RE: [jgit-dev] JGit translatability issue

["Zivkov, Sasa" <sasa.zivkov@xxxxxxx>]

> > My next idea was to actually specify the translation key as the
> attribute value:
> >
> > @Command(common = true, usage = "createAnEmptyRepository")
> >
> > and then get the proper translation at the place where --help logic
> is.
> > However, printing help text is part of the args4j library.
> > Additionally, this approach would be ugly because the translation key
> > would be given as a string and the compile type check provided by
> > using NLS/TranslationBundle "framework" would be lost.
>
> Yikes.  This is a problem.
>
> Our Main class doesn't do this, but args4j supports localization
> via ResourceBundles.  Most of the methods related to printing usage
> already take a ResourceBundle argument (in an overloaded form from
> what we use now).
>
> However the localization is done by your 2nd example above, where
> the usage, help or metavar attributes of the annotation are the
> resource bundle key.  Unfortunately there is no way for Eclipse's
> native NLS utilities to help us validate everything is translated.

I pushed the change:
http://egit.eclipse.org/r/#change,598

to get an early feedback if the string externalization is going
in the right direction.


>
> This is ugly, but I wonder if you couldn't use a similar NLS
> structure as we use for other translations:
>
>   public class Text extends NLS {
>     public static final String fooUsage = "fooUsage";
>   }
>
>   @Command(common = true, usage = Text.fooUsage)
>
> The trick being, the string is static final, and is set to the name
> of the resource property (so the method name).  Though there is a
> chance that these can get out of sync.  :-\

For now I didn't do that but used the translation key as string literal
directly in the annotation. It seems to me that having the translation key
repeated two times (in the constant name and the constant value)
doesn't bring much value as most of the strings will be used from one place
only.

Sasa Zivkov