Looks like it's not a good idea to have tons of small .properties files scattered all through the src directories -- unless we find some other tool that handles that better.
One single monolithic messages.properties as we have now is awful and inconvenient: programmers writing their own test elements now need to edit that file, and redo their changes on every upgrade... or go their own way. Plus the messages lack context, which makes a correct translation very difficult.
One .properties file per package would not improve things much, because we often classes in the same package defined in separate source directories (e.g. org.apache.jmeter.timers exists both in src/core and src/components). It can be discussed whether this is a mistake.
One .properties file per src directory would be better, but it's not obvious to implement using the standard JDK APIs.
The best approach is, IMO, one .properties file per component or bean. But then a tool to handle the translation process is a must. I'm building a long-list for that:
- RBManager
http://oss.software.ibm.com/icu4j/demo_tools/RBManager.html
- Zaval JRC Editor http://zaval.org/products/jrc-editor/download/index.html
- I18NEdit
http://www.cantamen.com/i18nedit.php
Do you know of any other candidates?
-- Salut,
Jordi.
En/na peter lin ha escrit:
:)
I'd have to say one per bean is more common from my
own experience. either way, i have no objections.
peter lin
--- Jordi Salvat i Alabart <[EMAIL PROTECTED]> wrote:
Being lazy, I'd rather choose one .properties file
per bean: it makes keys shorter to type (no need to copy/paste the
prefixes) and easier to find (since files are much smaller).
On the maintenance side, I'm looking at RBManager: RBManager:
http://www-106.ibm.com/developerworks/library/j-rbmgr/?article=xr
http://oss.software.ibm.com/icu4j/demo_tools/RBManager.html
I'll report in a while.ConstantThroughputTimer.throughput.displayName=Target
Salut,
Jordi.
En/na peter lin ha escrit:
I really have no preference for the naming
convention.
the one you have looks fine to me.
since I'm lazy, having per package or per protocol properties would be nice and reduce the number of properties files.
:)
peter
--- Jordi Salvat i Alabart <[EMAIL PROTECTED]>
wrote:
Opposite to what I said about Editors and
BeanInfos,
which have a default place to live in defined by the JavaBeans
standard, the location of resources was of my own choice, so we just need
to decide what's preferrable.
The alternative is to have a messages.properties
(global or per-package), but we need an established naming
scheme, so in the best case it would be like:
ConstantThroughputTimer.displayName=Constant Throughput Timer ConstantThroughputTimer.delay.displayName=Delay before each affected sampler
ConstantThroughputTimer.throughput.shortDescription=Maximumthroughput (in samples per minute)
---------------------------------------------------------------------number of samples you want to obtain per minute, per thread,
from all affected
samplers.
I'm not for one or the other option. What's more usual in Java applications?
Q: Is there any tools out there to maintain
localization .properties files? There must be one!
-- Salut,
Jordi.
En/na BAZLEY, Sebastian ha escrit:
Is the idea to move all the Bean-related
properties from
messages.properties to
<classname>Resources<lang>.properties?
It seems to me that this will result in a lot of
property files to create,
translate, test and maintain.
I can see that it is useful to be able to have
more than one set of property
files, but one set per class is rather a lot -
would it be possible to
combine these in sets at the package (or some
parent package) level?
Just a thought ...
S
---------------------------------------------------------------------To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
__________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus"
Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
---------------------------------------------------------------------To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
__________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
