Re: [jgit-dev] JGit translatability issue

["Shawn O. Pearce" <spearce@xxxxxxxxxxx>]

"Zivkov, Sasa" <sasa.zivkov@xxxxxxx> wrote:
> Just started working on externalizing strings in JGit into translation
> bundles and hit the first issue. The help text for JGit commands
> and options is written using annotations. Example:
> 
> @Command(common = true, usage = "Create an empty git repository")
> class Init extends TextBuiltin {
>         @Option(name = "--bare", usage = "Create a bare repository")
>         private boolean bare;
> ...
> }
> 
> The problem is that the values of annotation attributes must be compile
> time constants... so writing something like
> 
> @Command(common = true, usage = InitText.get().createAnEmptyRepository)
> 
> fails with a compiler error.
> 
> 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.

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.  :-\

Sadly, not everything in the localization world is perfect.

-- 
Shawn.