i18n of nukes. What is the way to go?
janoz Apr 1, 2004 6:37 AMI'm currently working on a dutch translation of the nukes core and I have a few questions.
I wanted to make de different display names in the modules part of the main menu i18n sensitive. This kan be done by changing the display name in the jboss-service.xml to a label in the Resource.properties.
Example from the user module:
<attribute name="Configuration"> <module> <operation name="edituser" display-name="{user._CHANGEYOURINFO}" description="Change your informations" image="info.gif" hint=""/> <operation name="memberlist" display-name="{user.MemberList}" decription="See all members of your comunity" image="" hint=""/> <operation name="logout" display-name="{core._LOGOUTEXIT}" description="Exit Nuke" image="exit.gif" hint=""/> </module>
Is this method advisable, should this be done in this way or will there be another system to deal with i18n of module names? (All the above display names have a $ in front, but nukes translates thes I just noticed in the preview)
While traversing the Resource properties I also noticed some other things. There are still many hardcoded strings in the java classes and the module.html (also some wrong labels. For instance the websitename label in the 'your not old enough, sorry' screen). Althoug for many of them there is an equivalent in the resources. In that case I just replaced the text with the label. For some there isn't a label so I added them to the resources. Since I found missing references I was wondering if you where still using them or that they are simply there because they where there in the php version and aren't maintained.
There isn't yet a standerd for names. Sometimes it is prefixed with an underscore. Some are uppercase with or without underscores as word separators and others are in camelcase. Since I'm adding a lot of labels I wanted to know which one will be the to be prefered style. Maybe I will even convert some old propertie names.
And finaly. The whole nukes resources is greatly aimed at Locale.US. Since I am going to use nukes in a strictly dutch enviroment I want to use only dutch. I can change the US reverence to an nl (dutch) Local in CoreModule.java but an imho more logical aproach would be a Local-less standard Resource.properties. This way the default language doesn't depend on a certain localisation. During the deploymend fase of the build project the prefered Resources can be copied to the default. Maybe I'm talking noncens, but that is the way I do it in a struts project of mine. The gain of this aproach is that, if there is no match of the local's of nukes and the prefered local's of the visitor, a default resource chosen at deploy time is used in stead of the US one.
I'm working with the nightly builds.