I was in London the other day to meet with Dave from Interface21 and two colleagues of mine (cheers to Scott and Lucas). One topic of the meeting was related to domain modeling. During the discussion we tried hard to come up with a decent name for a component in our domain model, but couldn’t figure out a descriptive name that would serve our needs well enough.
We were playing around with different names and - you know how that happens during meetings that take the whole day and you start loosing track for a couple of seconds - we started to look for names in other languages than English.
That moment I thought about a custom namespace that is properly the most useless one can think of: A translation of the Spring beans XSD into other languages. This idea sounds like non-sense in the first place, but on my way back at the Heathrow airport I couldn’t resist to think about it in more detail. Finally I ended up scratching a rapid prototype that allows to write bean definitions in my mother language:
<bohnen xmlns="http://www.sfw.org/schema/beans-german"
xsi:schemaLocation="http://www.sfw.org/schema/beans-german
http://www.sfw.org/schema/beans/spring-beans-german-2.0.xsd">
<bohne id="pet1" klasse="org.springframework.beans.Pet">
<eigenschaft name="name" wert="kitty1" />
</bohne>
<bohne id="pet2" klasse="org.springframework.beans.Pet">
<konstruktor-arg wert="kitty2" />
<eigenschaft name="spouse" ref="pet1" />
</bohne>
</bohnen>
Still, I don’t really see how a translation of the Spring beans XML configuration dialect into other languages can be useful for anyone, but there is already a request for translating Spring’s Exception message to other languages somewhere on the forums.
So what is the story of the post then?
There is one aspect of the preceding example, which I overlooked at the beginning, that could actually become quite useful. As you can see in the example there is not a single XML element from the original Spring dialect used to wire up two Beans. Certainly the syntax looks quite the same as plain Spring, but that is only an example. Even the root beans element is not used.
I wasn’t aware of the fact that with using Spring 2.0 namespaces you can introduce your own DSL to configure components without being tied to Spring’s XML syntax in any way. I haven’t seen a namespace example before that doesn’t use the beans element at least at the root level.
Consequently Spring allows mixing configuration files with different syntax in one ApplicationContext. So you can use a configuration file for your domain services or repositories that uses a Domain Specific Namespace and others for your technical infrastructure services, like transaction or security, that leverage the power of Spring’s XML syntax.
That could be very handy if you are working on a project that applies pattern following DDD. Furthermore that shows how flexible the Spring container is in terms of XML configuration since the introduction of custom namespaces with version 2.0.
The prototype source code of the German namespace handler is available here.
I think this can be really useful. There might be certain part of an application which the user may change according to his own taste. He then needs a configuration file which is generally a property file, but sometimes a more complex configuration structure is needed and the Spring XML is a good candidate for that. Doing it in his own language would definitely be a bonus.
Being a pioneer for Localization and Usability for over a Decade now (including the first ever Swing Localizations for Western Europe more than 3 years before Sun finally introduced it, too) this seems quite tempting to me.
One of Spring’s 2 founders also being from Austria like myself, probably explains, why it’s German first.
I just hope, Juergen is doing checks on this occasionally, so there are no weird bugs and wordings like in previous releases of the Countries Tutorial? (which I helped to fix ;-)
At my current customer I also whiteness some of their customers (large Multinational companies) demanding Content in their own language.
E.g. German, Dutch or Scandinavian names for folders, portlets or even URL sub-parts. Having something like Spring Beans or XSDs in those languages may help fulfill some of their demands, too.
As long as nobody comes up with the Programming Language (Java) itself using local languages or even “Umlauts” such as Microsoft’s attempt of local VB dialects in the 90s, I’m fine with that.
Hi!
I don’t like the idea of localizing configuration files (for an example of how bad this can become, just take a look at the fact that the “localization” of the VB inside MS-Office makes it a complicated thing to work with)… just imagine if java gets localized one time (”importa” instead of “import”, “paquete” instead of “package”… and then buggy precompilers that translate that from english to spanish to whatever-anyone-speaks… for me it sounds as maintenance nigthmare)…
And then, comes the problem with exceptions…localizing exceptions seems like a good idea at first (now we will be able to read them in spanish), and the comes the problems in the forums (not all languages have the same number of experts… and english is generally the one with more experts) so, when you have to find the way to translate you exception precisely to the exact way it is written in english, so that you can take advantage of the knowledge already generated in english forums (a real pain…) that way I prefer to install my computer with everything in english… if Spring is going to get more localized… it should be in a way that it is really easy to “complety turn off” (btw, do you know how to do that for java when installed in a localized way?)