One more duplicate message: APPLICATION_IS_ALREADY_REGISTERED
by Sean Flanigan
The duplicated message in
/org.jboss.tools.jst.web/src/org/jboss/tools/jst/web/messages/messages.properties
APPLICATION_IS_ALREADY_REGISTERED=Application {0} is already
registered in {1}
APPLICATION_IS_ALREADY_REGISTERED=Application is already registered.
is used in these methods:
org.jboss.tools.jst.web.context.RegisterServerContext.getErrorMessage()
org.jboss.tools.jst.web.server.RegistrationHelper.getRegistrationError(IModule,
String, IServer)
The odd thing is, both methods provide the NLS.bind parameters -
return NLS.bind(WebUIMessages.APPLICATION_IS_ALREADY_REGISTERED,
applicationName, targetServers[i].getName()); //$NON-NLS-2$
return NLS.bind(WebUIMessages.APPLICATION_IS_ALREADY_REGISTERED,
appname, server.getName());
- but at runtime, the first definition will be ignored, and NLS will use
the simple string "Application is already registered."
I can't work out how the duplicate got in, since they are on adjacent
lines, and it predates the Exadel import, so "svn blame" doesn't help.
I propose to delete the second definition. I'm pretty sure the
intention is to use the first message which takes parameters to provide
a better error message, and the string is already being passed to
NLS.bind, so it should be a perfectly safe change.
This will change the message used at runtime, but hopefully for the
better. Any objections?
--
Sean Flanigan
Senior Software Engineer
Engineering - Internationalisation
Red Hat
15 years
ResourceBundle hygiene: help out the translators
by Sean Flanigan
Hi everyone,
These are a few things that would really make the translators' jobs
easier. (And mine, to some extent ;-)
1. Delete messages which are already obsolete:
Please look at the apparently unused messages in this jira:
https://jira.jboss.org/jira/browse/JBIDE-4044 and help us work out if
they are really unused, so that they can be removed.
And if you know of any other messages (or entire properties files) which
can be removed, that will help too!
2. Delete messages which become obsolete in future:
When removing code which has (or might contain) externalised strings,
please check whether you can delete the strings from the relevant
properties files. This will save translators from translating text
which will never be used!
3. Please *please* avoid concatenating externalised strings like
messages.properties:
InvalidFilename1=The filename '
InvalidFilename2=' is not valid.
MyClass.java:
setMessage(Messages.InvalidFilename1 + filename +
Messages.InvalidFilename2);
I'm not a translator, but I understand it's not possible to translate
two half-sentences, jam them together with a variable in between, and
have the result mean anything useful in most languages. Unless the two
languages have the same word-order (eg English -> Pig Latin) the
*sentence will break*.
Instead, use a single string, passed though MessageFormat like this:
messages.properties:
InvalidFilename=The filename ''{0}'' is not valid.
MyClass.java:
setMessage(MessageFormat.format(Messages.InvalidFilename, fileName));
(Note that MessageFormat requires single quotes (apostrophes) to be
repeated.)
4. If some of the strings in a .properties file aren't meant to be
translated (eg an HTML template, or the text of a license agreement),
adding NON-TRANSLATABLE comments will ensure that the string/strings
aren't sent off for translation.
For example:
# START NON-TRANSLATABLE
def_sc_js_html_content=<script type\="text/javascript">\n\t\n</script>
# END NON-TRANSLATABLE
If you have a whole block of non-translatable properties, you can just
put # START NON-TRANSLATABLE before the first, and # END
NON-TRANSLATABLE after the last. (And yes, you can nest
NON-TRANSLATABLE blocks if you really want to.)
http://wiki.eclipse.org/Eclipse_Globalization_Guidelines#Non-translatable...
Your help is appreciated!
Thanks,
Sean.
PS I've updated
http://www.jboss.org/community/wiki/JBossToolsCodingGuidelines with
these points.
--
Sean Flanigan
Senior Software Engineer
Engineering - Internationalisation
Red Hat
15 years
org.jboss.tools.seam.xml vs org.jboss.tools.seam.pages.xml ?
by Sean Flanigan
These two plugins share a largish plugin.properties file which seems to
be identical.
/org.jboss.tools.seam.xml/plugin.properties
/org.jboss.tools.seam.pages.xml/plugin.properties
Are there perhaps a lot of old messages sitting in one of these files?
Sean.
--
Sean Flanigan
Senior Software Engineer
Engineering - Internationalisation
Red Hat
15 years
