Re: [ptp-dev] Externalized messages on PTP

[Chris Recoskie <recoskie@xxxxxxxxxx>]

> 1. Having an independent plugin to centralize all the externalized
> strings for whole PTP project.
> --For this approach, I think getString() is better choice

I would veto this anyway, as this would mean none of the plugins would work standalone.

===========================

Chris Recoskie
Team Lead, IBM CDT Team
IBM Toronto
http://www.eclipse.org/cdt

Hong Chang Lin <linhongc@xxxxxxxxxx>

Hong Chang Lin <linhongc@xxxxxxxxxx>
Sent by: ptp-dev-bounces@xxxxxxxxxxx

09/03/2008 09:36 PM

Please respond to
Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>

To	Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
cc
Subject	Re: [ptp-dev] Externalized messages on PTP

I found I made mistake, let me clear my thoughts:

1. Having an independent plugin to centralize all the externalized strings for whole PTP project. 
--For this approach, I think getString() is better choice

2. Let each plugin to have its own package to contain Messages.java and messages.properties. This is Greg's opinion, I misunderstood it as the 1st one.
--For this approach, static properties in Messages is better

Since many PTP plugins already follow the 2nd approach, it' easier to make it as the PTP guideline.


Best Regards,

------
Hongchang Lin

Greg Watson <g.watson@xxxxxxxxxxxx>

Greg Watson <g.watson@xxxxxxxxxxxx>
Sent by: ptp-dev-bounces@xxxxxxxxxxx

09/04/2008 12:48 AM

Please respond to
Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>

To	Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
cc
Subject	Re: [ptp-dev] Externalized messages on PTP

I prefer the static properties in the Messages class unless anyone feels strongly about getString.

Greg

On Sep 3, 2008, at 11:03 AM, Hong Chang Lin wrote:

Re: The former is better if Greg's suggestion is adopted; the latter one is good for Daniel's

- Will we use a getString (or similar) method to read the string for a given key? Or will we use the "public class Messages extends NLS" as adopted by Eclipse Platform (each message is a static property in the Messages class that extends NLS, and all are strings automatically read from the properties file once the class is referenced for the first time)?



Best Regards,

------
Hongchang Lin

<graycol.gif>Daniel Felix Ferber <dfferber@xxxxxxxxxxxxxxxxxx>

Daniel Felix Ferber <dfferber@xxxxxxxxxxxxxxxxxx>
Sent by: ptp-dev-bounces@xxxxxxxxxxx

09/03/2008 09:03 PM


Please respond to
Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>

<ecblank.gif> To	<ecblank.gif> Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
<ecblank.gif> cc	<ecblank.gif>
<ecblank.gif> Subject	<ecblank.gif> Re: [ptp-dev] Externalized messages on PTP

<ecblank.gif>

<ecblank.gif>


I still prefer using Eclipse tool to externalize strings. (right clicking over the package or source file and then Source->Externalize Strings).
By default, it externalizes strings into a messages.properties and a Messages.java file inside the same package.

Fortunately, it is also possible to change setting of the externalize dialog to put messages into a messages.properties and a Messages.java from another package. That would fit the approach described by Greg.
However, the dialog needs to be re-configured for every java file that it analyses. Unfortunately, the dialog does not remember the settings, nor are there preferences.

Therefore, Gregs suggestion would be fine for me, since it also works with the automatic externalization tool, although in a more cumbersome way.

I think there are other decisions to be taken:
- Will we use a getString (or similar) method to read the string for a given key? Or will we use the "public class Messages extends NLS" as adopted by Eclipse Platform (each message is a static property in the Messages class that extends NLS, and all are strings automatically read from the properties file once the class is referenced for the first time)?
- Are we going to use a prefix for the keys that identify the strings? By default, the externalization dialog uses the class name as prefix, other other (including none) prefixes are possible.

Best regards,
Daniel Felix Ferber

Greg Watson wrote:
I'm going to suggest that we adopt Chris's approach. Each plugin will have an org.eclipse.ptp.xxx.messages package which will contain Messages.java and messages.properties.

If anyone has an objection to this, let me know. Otherwise, I'll add it to our developer guidelines page: http://wiki.eclipse.org/PTP/developer_guidelines

Greg

On Aug 25, 2008, at 9:24 PM, Hong Chang Lin wrote:
Eclipse has two guidelines or two usual ways to externalize messages:

1. As Chris does in CDT, have an independent plugin to centralize all the externalized messages.
2. As many PTP plugins doing currently, have Message.java and message.properties for each plugin to externalize the strings on that plugin.

I guess people like the one which is easier to achieve from what we have now.


Best Regards,

------
Hongchang Lin

<graycol.gif>Beth Tibbitts <tibbitts@xxxxxxxxxx>
Beth Tibbitts <tibbitts@xxxxxxxxxx>
Sent by: ptp-dev-bounces@xxxxxxxxxxx

08/26/2008 02:47 AM


Please respond to
Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>

<ecblank.gif> To	<ecblank.gif> Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
<ecblank.gif> cc	<ecblank.gif>
<ecblank.gif> Subject	<ecblank.gif> Re: [ptp-dev] Externalized messages on PTP

<ecblank.gif>

<ecblank.gif>


Yes I just think we need some consistency - or at least encouragement to do something somewhat consistent - as you said we haven't always done this.
In the parts of PLDT where I used messages, I usually just put a getResourceString() in the plugin class and put a messages.properties in the directory of the base package in each plugin.
I think that's OK too, but anything more consistent than what we have now (no policy) is probably fine too.


...Beth

Beth Tibbitts (859) 243-4981 (TL 545-4981)
High Productivity Tools / Parallel Tools http://eclipse.org/ptp
IBM T.J.Watson Research Center
Mailing Address: IBM Corp., 745 West New Circle Road, Lexington, KY 40511

<graycol.gif>Greg Watson ---08/25/2008 02:08:43 PM---No, there's no policy, but now seems like a good time to make one. I
Greg Watson <g.watson@xxxxxxxxxxxx>
Sent by: ptp-dev-bounces@xxxxxxxxxxx

08/25/2008 01:41 PM


Please respond to
Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>

<ecblank.gif> To	<ecblank.gif> Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
<ecblank.gif> cc	<ecblank.gif>
<ecblank.gif> Subject	<ecblank.gif> Re: [ptp-dev] Externalized messages on PTP

<ecblank.gif>

<ecblank.gif>


No, there's no policy, but now seems like a good time to make one. I  
notice that Chris has created an org.eclipse.ptp.rdt.core.messages  
package with Messages.java and messages.properties. This seems like a  
good idea to me. Anyone have any strong feelings about this?

Greg

On Aug 25, 2008, at 10:28 AM, Daniel Felix Ferber wrote:

> Hi,
>
> Are there policies about how to externalize string on PTP (where to  
> put the .properties file, names for the constants of strings, and so  
> on)? I took a look at the wiki but did not find information about.
>
> Best regards,
> Daniel Felix Ferber
> _______________________________________________
> ptp-dev mailing list
> ptp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ptp-dev
>

_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev

<2A276323.gif>_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev

_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev





---


_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev
_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev

_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev

_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev

_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev