On Mon, 2006-25-09 at 18:26 -0700, Jody Garnett wrote:
> Richard Gould wrote:
> > Ok, so it is unanimous that the NL1 fragments should be clobbered, and
> > that the number of properties files should be reduced as much as
> > possible.
> >
> > So I alter my proposal a little:
> >
> > 1) Rename Policy to Messages. One per plug-in. It resides in
> > $PLUGIN_NAME.internal.Messages.
> > 2) Rename Policy.bind(${key}) to Messages.getString(${key})
> >
> > Those two changes will make using the Eclipse Externalize Strings wizard
> > much easier. This is mostly for us uDig developers.
> >
> Okay, so we will have some wiki pages to update as part of this
> recommendation :-) I really want to be sure this
> is a researched solution, ensuring that the bundles are unloaded as part
> of plug-in lifecycle and so on. What does
> our happy "building commercial quality plug-ins" book recommend?
It was their recommendation that we went with, and that is what brought
us to this point.
> > 3) Eliminate the NL1 fragments
> > 4) Move all messages.properties files to live in the same package as
> > their Messages class ($PLUGIN_NAME.internal)
> >
> Cannot remember if that is how things are supposed to work out :-( I
> recall a slightly different structure was recommended, where
> the directories captured the language (so as to support different icons
> and images for each language).
Yes, but this does not apply to the properties files. Icons, help, and
other internationalized items go in an nl/ directory.
> > So each plugin will have two properties files: messages.properties (for
> > Java code) and plugin.properties (for plugin.xml strings)
> >
> > As for unmaintained languages, I believe it is possible to easily leave
> > them out of an export, so they can be left beside the original english
> > in subversion.
> >
> > (I think there is a field on the product export that allows you to
> > specify which languages should be exported)
> >
> > Cheers,
> >
> > Richard
> >
> >
> > On Sat, 2006-23-09 at 12:20 -0700, Jody Garnett wrote:
> >
> >> Jesse Eichar wrote:
> >>
> >>> My vote is:
> >>>
> >>> ±0 for replacing Policy with Messages.
> >>>
> >> -1, Policy is used a lot in the core eclipse plugins, and offers a lot
> >> more then the auto generated "Messages" class (in terms of setting up
> >> progress monitors and the like).
> >>
> >>> +1 for dropping all those NL1 fragments that don't have code/images/...
> >>>
> >> +1, less plug-ins the better
> >>
> >>> -1 for messages.properties in (nearly) every package.
> >>>
> >> -1, less properties files to hunt down the better.
> >>
> >>> +1 for moving orphaned languages out of trunk until someone cares again.
> >>>
> >> +/- 0, I can see this both ways, can we leave them there (in case
> >> someone cares) and simply leave them out of our plug-in export?
> >>
> >> Cheers,
> >> Jody
> >> _______________________________________________
> >> User-friendly Desktop Internet GIS (uDig)
> >> http://udig.refractions.net
> >> http://lists.refractions.net/mailman/listinfo/udig-devel
> >>
> >
> > _______________________________________________
> > User-friendly Desktop Internet GIS (uDig)
> > http://udig.refractions.net
> > http://lists.refractions.net/mailman/listinfo/udig-devel
> >
>
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
