Anyway, I got it now and have committed and acked your contribution!
I'm happy that I am of help.
We are waiting for Collab.NET to migrate our CVS repository to SVN.
YES! I've switched from CVS to SVN three years ago, and going back to CVS
was such a pain
This reminds me that right now we have many of the properties files
scattered all over the place so the whole translation
procedure might be
a bit difficult for people that don't know the project well. We'd
probably have to make an effort and either change our resource loading
policy or extract all these files and make them available somewhere so
that volunteers could easily translate them. I think I'd prefer the
I'd also say that the latter approach would be nicer, but are you thinking
about somewhere else in the sources or in the installation directory? If
they would be placed as separate files in the installation directory,
contributors could edit the translations without having to care about the
source and build process. The drawback would be that there would be more
work for the installer authors, since the directory layout and classpath
setting would become more complex. Speaking of classpath, since the resource
files are looked up through the class loader, and the OSGi framework has its
own classloader, I don't know if it would even be possible to load resources
which are not in the bundle JAR, making my previous ideas moot.
Stuffing the properties files in a separate directory in the source tree
would be no problem, since the build.xml could be changed so that the
properties files are put into the correct JAR files. This would mean
increasing the complexity of the build file, however, and could become a
maintenance problem in my opinion.
Perhaps it would be best to ask would-be contributors if they can work with
the existing layout and change it according to their needs.
We'd probably also need to accompany these with a short wiki
entry in "Developer Documentation" explaining how to do the
Your comments in the various posts and in messages.properties
much what we need. Are you interested in authoring a short translation
manual on our wiki? Let me know if so and I'll create a user for you.
Yes, I'd be happy to do that.
Another thing that we need to do is figure how to handle language
selection in a user friendly way. It is probably a good idea
to have our
platform specific installers (rpm, deb, exe, dmg) set the
property the same way you do (isn't java supposed to be doing this
automatically btw?). Another nice thing to have (but probably a bit
tricky to implement) would be to add a configuration form in
the UI that
would allow the user to override system-wide settings (Hope we'll have
the time do this one of these days). Other suggestions?
The user.language... properties are indeed set automatically by the Java
runtime based on the operating system settings. They are normal system
properties which can be queried with System.getProperties() and are used to
initialize the default locale (see Locale.getDefaultLocale()). (At least
this is how it works with the Sun JVM.) I added the override to the
build.xml so you can easily test SIP-Communicator with languages other than
your system language.
Changing the language based on user selection would mean to change the
default locale with Locale.setDefaultLocale(). The ResourceBundle uses the
default locale to select the translation bundle to load if no language is
specified explicitly. This would have to be done before the SIP Communicator
resources are loaded. My personal feeling is however that per-application
language settings are somewhat superfluous (except for debugging) and using
the system language is ok.