Internationalization and enums

[Hayward Hulick]

It appears that Java enums are not of much use when Internationalization
(I18n) is a concern. The values are hardcoded and can't be changed without
recompiling. While variables could be added to include the I18n information
in the enum class, all related methods and variables would have to be
re-coded for each enum since enums can't be subclassed. Can anyone suggest
a way around this problem? If not, I guess I'll just have to create my own
class with static final values.

Hayward Hulick

 

[Bent C Dalager]

It appears that Java enums are not of much use when Internationalization
(I18n) is a concern. The values are hardcoded and can't be changed without
recompiling. While variables could be added to include the I18n information
in the enum class, all related methods and variables would have to be
re-coded for each enum since enums can't be subclassed. Can anyone suggest
a way around this problem? If not, I guess I'll just have to create my own
class with static final values.

It's not entirely clear why i18n conflicts with enums in your case,
but if I were to guess I would say that your problems may be solved by
overriding toString() in the enum class to ensure that it supports
i18n.

I am assuming that what you are trying to internationalize is program
output rather than the source code itself.

Cheers
Bent D

 

[Thomas Fritsch]

It appears that Java enums are not of much use when Internationalization
(I18n) is a concern. The values are hardcoded and can't be changed without
recompiling. While variables could be added to include the I18n information
in the enum class, all related methods and variables would have to be
re-coded for each enum since enums can't be subclassed. Can anyone suggest
a way around this problem? If not, I guess I'll just have to create my own
class with static final values.

I suggest to override your enum's toString() method, so that it returns
a locale-dependent String.
There is more info in the API docs of Enum#toString,
ResourceBundle#getBundle and PropertyResourceBundle.
Below is a simple example for this approach.
When I run it (on my german system) I get an output with german Strings:
MERCURY: Merkur
VENUS: Venus
EARTH: Erde
MARS: Mars

// File de/tfritsch/Planet.java
package de.tfritsch;

import java.util.ResourceBundle;

public enum Planet {
MERCURY, VENUS, EARTH, MARS;

/** Resources for the default locale */
private static final ResourceBundle res =
ResourceBundle.getBundle("de.tfritsch.Res");

/** @return the locale-dependent name of the planet */
public String toString() {
return res.getString(name() + ".string");
}

/** Tests the toString() method for all constants. */
public static void main(String[] args) {
for (Planet value : values()) {
System.out.println(value.name() + ": " + value);
}
}
}


# File de/tfritsch/Res.properties
# default language (english) resources
MERCURY.string=Mercury
VENUS.string=Venus
EARTH.string=Earth
MARS.string=Mars


# File de/tfritsch/Res_de.properties
# german language resources
MERCURY.string=Merkur
VENUS.string=Venus
EARTH.string=Erde
MARS.string=Mars

.... (and so for French, Spanish, Russian, ...)

 

[Wojtek]

Hayward Hulick wrote :

It appears that Java enums are not of much use when Internationalization
(I18n) is a concern. The values are hardcoded and can't be changed without
recompiling. While variables could be added to include the I18n information
in the enum class, all related methods and variables would have to be
re-coded for each enum since enums can't be subclassed. Can anyone suggest a
way around this problem? If not, I guess I'll just have to create my own
class with static final values.

Hayward Hulick

public SomeClass
{
public enum MyEnum
{
VALUE_ONE("I18N_Key.for.one"),
VALUE_TWO("I18N_Key.for.two");

private String i18NKey;

private MyEnum(String i18N)
{
i18NKey = i18n;
}

public static String getI18NKey()
{
return i18NKey;
}
}
}


.....

String key = MyEnum.VALUE_ONE.getI18NKey();
.....

 

[Wojtek]

Hayward Hulick wrote :

It appears that Java enums are not of much use when Internationalization
(I18n) is a concern. The values are hardcoded and can't be changed without
recompiling. While variables could be added to include the I18n
information in the enum class, all related methods and variables would have
to be re-coded for each enum since enums can't be subclassed. Can anyone
suggest a way around this problem? If not, I guess I'll just have to
create my own class with static final values.

Hayward Hulick

public SomeClass
{
public enum MyEnum
{
VALUE_ONE("I18N_Key.for.one"),
VALUE_TWO("I18N_Key.for.two");

private String i18NKey;

private MyEnum(String i18N)
{
i18NKey = i18n;
}

public String getI18NKey()
{
return i18NKey;
}
}
}


.....

String key = MyEnum.VALUE_ONE.getI18NKey();
.....

 

[Thomas Fritsch]

public SomeClass
{
public enum MyEnum
{
VALUE_ONE("I18N_Key.for.one"),
VALUE_TWO("I18N_Key.for.two");

private String i18NKey;

private MyEnum(String i18N)
{
i18NKey = i18n;
}

public String getI18NKey()
{
return i18NKey;
}
}
}


....

String key = MyEnum.VALUE_ONE.getI18NKey();
....

There is no need to introduce an additional variable (i18NKey) as key.
You can use the programmatic name ("VALUE_ON", "VALUE_TWO") as key:
String key = MyEnum.VALUE_ONE.name();

 

[Hayward Hulick]

It appears that Java enums are not of much use when
Internationalization (I18n) is a concern. The values are hardcoded and
can't be changed without recompiling. While variables could be added to
include the I18n information in the enum class, all related methods and
variables would have to be re-coded for each enum since enums can't be
subclassed. Can anyone suggest a way around this problem? If not, I
guess I'll just have to create my own class with static final values.

I suggest to override your enum's toString() method, so that it returns a
locale-dependent String.
There is more info in the API docs of Enum#toString,
ResourceBundle#getBundle and PropertyResourceBundle.
Below is a simple example for this approach.
When I run it (on my german system) I get an output with german Strings:
MERCURY: Merkur
VENUS: Venus
EARTH: Erde
MARS: Mars

// File de/tfritsch/Planet.java
package de.tfritsch;

import java.util.ResourceBundle;

public enum Planet {
MERCURY, VENUS, EARTH, MARS;

/** Resources for the default locale */
private static final ResourceBundle res =
ResourceBundle.getBundle("de.tfritsch.Res");

/** @return the locale-dependent name of the planet */
public String toString() {
return res.getString(name() + ".string");
}

/** Tests the toString() method for all constants. */
public static void main(String[] args) {
for (Planet value : values()) {
System.out.println(value.name() + ": " + value);
}
}
}


# File de/tfritsch/Res.properties
# default language (english) resources
MERCURY.string=Mercury
VENUS.string=Venus
EARTH.string=Earth
MARS.string=Mars


# File de/tfritsch/Res_de.properties
# german language resources
MERCURY.string=Merkur
VENUS.string=Venus
EARTH.string=Erde
MARS.string=Mars

... (and so for French, Spanish, Russian, ...)

Thank you. Your solution is a lot simpler than the one I came up with,
and doesn't involve a lot of extra code to be repeated in every enum.
Thanks again.

Hayward

 

[Roedy Green]

It appears that Java enums are not of much use when Internationalization
(I18n) is a concern. The values are hardcoded and can't be changed without
recompiling. While variables could be added to include the I18n information
in the enum class, all related methods and variables would have to be
re-coded for each enum since enums can't be subclassed. Can anyone suggest
a way around this problem? If not, I guess I'll just have to create my own
class with static final values.

the enum name appears only inside code. It is merely a default for
external use. You can write your own internationalised enum toString
or valueOf

 

[Wojtek]

Thomas Fritsch wrote :

There is no need to introduce an additional variable (i18NKey) as key.
You can use the programmatic name ("VALUE_ON", "VALUE_TWO") as key:
String key = MyEnum.VALUE_ONE.name();

Not if you organize your I18N.

Mine looks a lot like:

report.finance.yearly.total

and

system.admin.control.blockLogin