i18n of nukes. What is the way to go?

[janoz]

I'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.

[triathlon98]

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.

This does not always do what you expect. When the requested locale is not found, Java does not default to the resource file without locale, but first to the default locale. So for this behaviour to work, you better first change the default locale to something nonexistent...

Joachim

[janoz]

I wasn't aware of that. I was aiming at this pasage in CoreModule.java (starting around line 375)

 // If nothing is right we will endup with en_US locale.
 Locale preferedLocale = Locale.US;
 for (Enumeration e = req.getLocales();e.hasMoreElements();)
 {
 Locale requestedLocale = (Locale)e.nextElement();
 ResourceBundle requestedResourceBundle = getResourceBundle(requestedLocale);

 // It returns Locale.US if tmpLocale is not supported
 if (!requestedResourceBundle.getLocale().equals(Locale.US))
 {
 preferedLocale = requestedLocale;
 break;
 }
 }

Maybe this should be a constant or even configurable. The same goes for the part in the constructor:

 public CoreModule(boolean persistent)
 {
 super(persistent);
 Locale locale = Locale.US;
 locales.add(locale);
 bundles.put(locale, new ResourceBundleAggregator(locale));
 locale = new Locale("nl");
 locales.add(locale);
 bundles.put(locale, new ResourceBundleAggregator(locale));
 }

But on the other hand. Adding some new resources requires a rebuild of the jar files so recompiling CoreModule isn't a big problem.

But that still leaves the label question and the codestandard for the resource.properties. Since I'm planning some rather large changes I would like to know if I'm doing the right thing.

[wellington.pinheiro]

I have the same problem than you Janoz, and I did the same thing on CoreModule.java.

I'm translating nukes for brazilian portuguese and I still don't know the best way to do that, but it works this way....

[adellechiaie]

OK, guys, I see that some of us out there is trying to do the translation.
Let's try not to do the same work five times, someone could give me some informations???
I think that Janoz is in the more advanced phase, could you give some directions???
Thank's in advance
Andrea

[julien1]

that would be appreciable, first thing is to clean the files to avoid cross-references (like the module user should not use items from module core, etc....)

[janoz]

My advantage is that we are goinig to use nukes in a proffesional enviroment (A dutch hospital).
I got a lot of additions and changes but I have no clue what to do with them. The same goes for some earlier problems:

But that still leaves the label question and the codestandard for the resource.properties. Since I'm planning some rather large changes I would like to know if I'm doing the right thing.