Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [LIKELY JUNK]Re: [egit-dev] Participation in Helios build?

Finally I had some time to work on this topic.
Just submitted the change:
http://egit.eclipse.org/r/#change,315

This only provides the "infrastructure".
No translation to any particular language is done within this change.


> -----Original Message-----
> From: egit-dev-bounces@xxxxxxxxxxx [mailto:egit-dev-
> bounces@xxxxxxxxxxx] On Behalf Of Shawn O. Pearce
> Sent: Donnerstag, 10. Dezember 2009 16:06
> To: EGit developer discussion
> Subject: Re: [LIKELY JUNK]Re: [egit-dev] Participation in Helios build?
>
> "Zivkov, Sasa" <sasa.zivkov@xxxxxxx> wrote:
> > > I'd actually prefer to just write our own micro NLS class in JGit.
>
> Chris Aniszczyk and I talked about this yesterday at the board
> meeting during a down minute.  What we actually need isn't static
> fields for translation, but instance fields we can inject based
> on the current client, because JGit can often be used in a server
> context where the translation of the error message might need to
> differ per-request to suite the user's preference.
>
> So we're thinking a pattern like:
>
>       public class TransportText extends TranslationBundle {
>               public static TransportText get() {
>                       return NLS.get(TransportText.class);
>               }
>
>               public String repositoryNotFound;
>               public String transportError;
>       }
>
>       TransportText_en_US.properties:
>               repositoryNotFound=repository {0} not found
>               transportError=unknown error talking to {0}
>
>       public abstract class TranslationBundle {
>               public void load(String language) {
>                       ... load bundle into instance members via reflection
> ...
>               }
>       }
>
>       public class NLS {
>               private static final InheritedThreadLocal<NLS> local = new
> InheritedThreadLocal<NLS>();
>               public static <T extends TranslationBundle> T get(Class<T>
> type) {
>                       NLS self = local.get();
>                       if (self == null) {
>                               self = new NLS(... JVM default ...);
>                       }
>                       return self.get(type);
>               }
>
>               private Map<Class, TranslationBundle> map = new HashMap();
>
>               public synchronized <T extends TranslationBundle> T
> get(Class<T> type) {
>                       TranslationBundle r = map.get(type);
>                       if (r == null) {
>                               r = type.newInstance();
>                               r.load(language);
>                               map.put(type, r);
>                       }
>                       return r;
>               }
>       }
>
> And code can throw exceptions:
>
>       throw new TransportException(
>               uri,
>               TransportText.get().transportError);
>
> Client code in applications or in application servers would need
> to set the NLS environment before starting JGit.
>
> This might be an issue with the worker thread pool in Eclipse,
> how do we ensure the workers get the NLS environment?
>
> > Few questions:
> > 1. How to decide if a text should or shouldn't be translated? Is it
> only error message as stated above?
> >    I assume (j)git output should stay parsable and some texts mustn't
> be translated. Right?
>
> IMHO, if the text is an english message that isn't a string required
> for a file name or file content or network protocol keyword, we
> should translate it.  That's *most* of the strings in the JGit code.
>
> > 2. How to find, at runtime, the set of classes where to perform the
> injection of translated texts?
> >    Is this already limited to particular packages only?
>
> Pretty much all of them.  :-(
>
> --
> Shawn.
> _______________________________________________
> egit-dev mailing list
> egit-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/egit-dev


Back to the top