The translator loads some resource bundles which are actually java
source files with mesages in hashmaps ...
e.g. --- see [1] ..
I don't understand why a java class is required for these messages ...
is there any reason you have not used standard i18n message bundles
which are essentially text property files ?
With those you can use standard tools to translate the error messges
for multiple languages and there is a default safe fallback behaviour
in case there is no message bundle for the current systme locale /
language ... and also it means we don't mix error messages into source
code as is currently there ...
Ashok
[1] ---
package org.un.bungeni.translators.localization;
import java.util.ListResourceBundle;
/**
* This class is used to set all the messages in English for Kenya
*/
public class Messages_it_IT extends ListResourceBundle {
//The List that contains the messages for kenya
static Object[][] contents =
{
{ "MISSING_ATTRIBUTE_LEFT_TEXT",
"L'informazione addizionale '" },
{ "MISSING_ATTRIBUTE_CENTER_TEXT",
"' è obbligatoria per la sezione '" },
{ "MISSING_ATTRIBUTE_RIGHT_TEXT",
"'" },
};
/**
* Return the list of the messages
* @Override
*/
protected Object[][] getContents()
{
//return the list of the messages
return contents;
}
}
Alright ...my point was more about default behaviour ... for instance,
my computer's locale is set to "en_US" ...
the translator has 2 locales (en_KE, and it_IT) ... and no default
locales ... i realized the translator was crashing because there was
no Messages_en_US.java file ... so if you try to run the translator on
a computer where the 2 existing locales dont exist it crashes... May i
suggest a default locale ?
for instance with translation message bundles ... :
I usually have "Messages.properties" as the default language message bundle
Depending on the current locale the system looks for
"Messages_fr_FR.properties" ... "Messages_it_IT.properties" as the
case maybe ... if those message locales are not available it falls
back to use Messages.properties ...