[cai18n-dev] Type safe message definition
Hi Ceki I have two type safe message definition idea. I've committed draft code to my cai18n project clone. (http://github.com/takeshi/cai18n/tree/master) Please take it in cai18n project, if you like it,. My ideas is as follows. 1. Message definition by annotation for instance, public enum LocalizedColors { @Message("green") GREEN { @Message("vert") Locale fr = Locale.FRANCE; @Message("midori") Locale ja = Locale.JAPAN; } } Using enum field declaration with annotation, we can define localized message. It is simple , but we can't add other locale. 2. Message definition by switch case for instance, public class ColorDef_fr extends MessageDefinition<Colors> { public Locale getLocale() { return Locale.FRANCE; } public String getMessage(Colors e) { switch (e) { case BLUE: return "blue"; case GREEN: return "vert"; case RED: return "rouge"; } return null; } } Using method return, we can define localized message. It is not simple, but this we can define it per locale.
Hi Takeshi, Thank you for sharing your new ideas. I just cloned http://github.com/takeshi/cai18n/tree/master. It looks like MessageDefinitionConveyor is referencing the class ch.qos.cai18n.sample.ColorMessageConfiguration (part of the tests). This causes the maven build to fail for me. I'll look at the code some more tomorrow morning and come back to you with comments. Cheers, Takeshi Kondo wrote:
Hi Ceki
I have two type safe message definition idea. I've committed draft code to my cai18n project clone. (http://github.com/takeshi/cai18n/tree/master) Please take it in cai18n project, if you like it,.
My ideas is as follows.
1. Message definition by annotation
for instance,
public enum LocalizedColors {
@Message("green") GREEN { @Message("vert") Locale fr = Locale.FRANCE;
@Message("midori") Locale ja = Locale.JAPAN; } }
Using enum field declaration with annotation, we can define localized message. It is simple , but we can't add other locale.
2. Message definition by switch case
for instance,
public class ColorDef_fr extends MessageDefinition<Colors> { public Locale getLocale() { return Locale.FRANCE; }
public String getMessage(Colors e) { switch (e) { case BLUE: return "blue"; case GREEN: return "vert"; case RED: return "rouge"; } return null; } }
Using method return, we can define localized message. It is not simple, but this we can define it per locale._______________________________________________
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
Hi Ceki I'm sorry. I'm working to 22 pm in Japan time(14 pm in French time). I'll update it until tomorrow morning. On 2009/08/28, at 6:11, Ceki Gulcu <ceki@qos.ch> wrote:
Hi Takeshi,
Thank you for sharing your new ideas. I just cloned http://github.com/takeshi/cai18n/tree/master .
It looks like MessageDefinitionConveyor is referencing the class ch.qos.cai18n.sample.ColorMessageConfiguration (part of the tests). This causes the maven build to fail for me.
I'll look at the code some more tomorrow morning and come back to you with comments.
Cheers,
Takeshi Kondo wrote:
Hi Ceki I have two type safe message definition idea. I've committed draft code to my cai18n project clone. (http://github.com/takeshi/cai18n/tree/master) Please take it in cai18n project, if you like it,. My ideas is as follows. 1. Message definition by annotation for instance, public enum LocalizedColors { @Message("green") GREEN { @Message("vert") Locale fr = Locale.FRANCE; @Message("midori") Locale ja = Locale.JAPAN; } } Using enum field declaration with annotation, we can define localized message. It is simple , but we can't add other locale. 2. Message definition by switch case for instance, public class ColorDef_fr extends MessageDefinition<Colors> { public Locale getLocale() { return Locale.FRANCE; } public String getMessage(Colors e) { switch (e) { case BLUE: return "blue"; case GREEN: return "vert"; case RED: return "rouge"; } return null; } } Using method return, we can define localized message. It is not simple, but this we can define it per locale._______________________________________________
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch _______________________________________________ cai18n-dev mailing list cai18n-dev@qos.ch http://qos.ch/mailman/listinfo/cai18n-dev
Hi Ceki I'm sorry. I'm working to 22 pm in Japan time(14 pm in French time). I'll update it until tomorrow morning. On 2009/08/28, at 6:11, Ceki Gulcu <ceki@qos.ch> wrote:
Hi Takeshi,
Thank you for sharing your new ideas. I just cloned http://github.com/takeshi/cai18n/tree/master .
It looks like MessageDefinitionConveyor is referencing the class ch.qos.cai18n.sample.ColorMessageConfiguration (part of the tests). This causes the maven build to fail for me.
I'll look at the code some more tomorrow morning and come back to you with comments.
Cheers,
Takeshi Kondo wrote:
Hi Ceki I have two type safe message definition idea. I've committed draft code to my cai18n project clone. (http://github.com/takeshi/cai18n/tree/master) Please take it in cai18n project, if you like it,. My ideas is as follows. 1. Message definition by annotation for instance, public enum LocalizedColors { @Message("green") GREEN { @Message("vert") Locale fr = Locale.FRANCE; @Message("midori") Locale ja = Locale.JAPAN; } } Using enum field declaration with annotation, we can define localized message. It is simple , but we can't add other locale. 2. Message definition by switch case for instance, public class ColorDef_fr extends MessageDefinition<Colors> { public Locale getLocale() { return Locale.FRANCE; } public String getMessage(Colors e) { switch (e) { case BLUE: return "blue"; case GREEN: return "vert"; case RED: return "rouge"; } return null; } } Using method return, we can define localized message. It is not simple, but this we can define it per locale._______________________________________________
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch _______________________________________________ cai18n-dev mailing list cai18n-dev@qos.ch http://qos.ch/mailman/listinfo/cai18n-dev
Hi Takeshi, For you information, CAI18N version 0.2 has been just released. On the top of the manual, it states: Acknowledgment The original idea behind CAI18N is attributed to Takeshi Kondo. It consolidated into what it is today subsequent to a discussion involving Ralph Goers, Ceki Gülcü, Takeshi Kondo and Pete Muir on the slf4j-dev mailing list. Cheers, -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
Hello Ceki Thanks for your attention. I'm happy to diffuse my idea buried for two years.I couldn't have done it without you. On 2009/08/28, at 20:36, Ceki Gulcu wrote:
Hi Takeshi,
For you information, CAI18N version 0.2 has been just released. On the top of the manual, it states:
Acknowledgment The original idea behind CAI18N is attributed to Takeshi Kondo. It consolidated into what it is today subsequent to a discussion involving Ralph Goers, Ceki Gülcü, Takeshi Kondo and Pete Muir on the slf4j-dev mailing list.
Cheers,
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch _______________________________________________ cai18n-dev mailing list cai18n-dev@qos.ch http://qos.ch/mailman/listinfo/cai18n-dev
Hello Takeshi, LocalizedColors and ColorDef_* show that it is possible to do localization without resource bundles. Is that the main point, or is there something else? The syntax of LocalizedColors is more verbose than what you would have with a simple enum + resource bundles. Actually, the syntax is overwhelmingly noisy to be useful, or I may be just missing the point. :-) The syntax of MessageDeclaration based enums is much better but still more verbose than the enum + resource bundles combination. MessageDefinitionConveyor demonstrates that an enum-only (or Java code only) implementation of IMessageConveyor is possible. But from a practical point of view, resource bundles are more convenient. Wouldn't you agree? In any case, thank you for sharing your ideas. They are well appreciated. Takeshi Kondo wrote:
Hi Ceki
I have two type safe message definition idea. I've committed draft code to my cai18n project clone. (http://github.com/takeshi/cai18n/tree/master) Please take it in cai18n project, if you like it,.
My ideas is as follows.
1. Message definition by annotation
for instance,
public enum LocalizedColors {
@Message("green") GREEN { @Message("vert") Locale fr = Locale.FRANCE;
@Message("midori") Locale ja = Locale.JAPAN; } }
Using enum field declaration with annotation, we can define localized message. It is simple , but we can't add other locale.
2. Message definition by switch case
for instance,
public class ColorDef_fr extends MessageDefinition<Colors> { public Locale getLocale() { return Locale.FRANCE; }
public String getMessage(Colors e) { switch (e) { case BLUE: return "blue"; case GREEN: return "vert"; case RED: return "rouge"; } return null; } }
Using method return, we can define localized message. It is not simple, but this we can define it per locale._______________________________________________ cai18n-dev mailing list cai18n-dev@qos.ch http://qos.ch/mailman/listinfo/cai18n-dev
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
Hello Ceki I don't like to write property file(because I must execute native2ascii to property file in Japanese) , but main point is IDE support. Because Enum and Annotation is in Java syntax, IDE inform quickly error to me in saving code. Verification approach can't check consistency on no execution. It don't utilize typed language advantage. IMO, the advantage of typed language like as Java and C# than dynamic language like as Ruby and Python is to inform error in compiling time. Japanese famous engineer Yasuo Higa have been creating excellent features from this concept. (see Tyep safe query: http://sites.google.com/site/slim3appengine/ Home ). I like this concept. What do you think about IDE support? On 2009/08/28, at 21:11, Ceki Gulcu wrote:
Hello Takeshi,
LocalizedColors and ColorDef_* show that it is possible to do localization without resource bundles. Is that the main point, or is there something else?
The syntax of LocalizedColors is more verbose than what you would have with a simple enum + resource bundles. Actually, the syntax is overwhelmingly noisy to be useful, or I may be just missing the point. :-)
The syntax of MessageDeclaration based enums is much better but still more verbose than the enum + resource bundles combination. MessageDefinitionConveyor demonstrates that an enum-only (or Java code only) implementation of IMessageConveyor is possible. But from a practical point of view, resource bundles are more convenient. Wouldn't you agree?
In any case, thank you for sharing your ideas. They are well appreciated.
Takeshi Kondo wrote:
Hi Ceki I have two type safe message definition idea. I've committed draft code to my cai18n project clone. (http://github.com/takeshi/cai18n/tree/master) Please take it in cai18n project, if you like it,. My ideas is as follows. 1. Message definition by annotation for instance, public enum LocalizedColors { @Message("green") GREEN { @Message("vert") Locale fr = Locale.FRANCE; @Message("midori") Locale ja = Locale.JAPAN; } } Using enum field declaration with annotation, we can define localized message. It is simple , but we can't add other locale. 2. Message definition by switch case for instance, public class ColorDef_fr extends MessageDefinition<Colors> { public Locale getLocale() { return Locale.FRANCE; } public String getMessage(Colors e) { switch (e) { case BLUE: return "blue"; case GREEN: return "vert"; case RED: return "rouge"; } return null; } } Using method return, we can define localized message. It is not simple, but this we can define it per locale._______________________________________________ cai18n-dev mailing list cai18n-dev@qos.ch http://qos.ch/mailman/listinfo/cai18n-dev
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch _______________________________________________ cai18n-dev mailing list cai18n-dev@qos.ch http://qos.ch/mailman/listinfo/cai18n-dev
Takeshi Kondo wrote:
Hello Ceki
I don't like to write property file(because I must execute native2ascii to property file in Japanese) , but main point is IDE support.
Because Enum and Annotation is in Java syntax, IDE inform quickly error to me in saving code. Verification approach can't check consistency on no execution. It don't utilize typed language advantage.
IMO, the advantage of typed language like as Java and C# than dynamic language like as Ruby and Python is to inform error in compiling time. Japanese famous engineer Yasuo Higa have been creating excellent features from this concept. (see Tyep safe query: http://sites.google.com/site/slim3appengine/Home ). I like this concept.
What do you think about IDE support?
I agree. IDE support is an important aspect of the problem. However, I don't think developers/translators would have much patience for a verbose format. Currently, CAI18N strikes a nice balance between complexity and usability, in accordance with the Pareto principle that Yasuo Higa refers to. IDE support would probably gel CAI18N as the i18n API of choice. I am pretty confident that one could enhance CAI18N for IDE support even if resource files are used. After all, a resource file is written in a very simple key=value "language". If an IDE plugin can support type checking for Java classes it can easily support checks for resource bundles. (If you can run, then you can surely walk.) More concretely, it all depends on the properties editor of the IDE and the extensions/hooks it supports. Adding IDE support for CAI18N would be a very nice sub-project. I have some experience developing Eclipse plugins. Do you have IDE development experience? -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
I agree. If there is IDE plugins, I'll fulfill my requirement by it. But I don't want to develop IDE plugins, because IDE plugin's maintenance is trouble-filled. If it must need IDE's plugins, I want to make it come true, IMO. Why don't we develop simple pattern of enum + annotation as message definition? for instance, public enum Colors{ @Value("green") GREEN, @Value("red") RED, @Value("blue") BLUE } This syntax is simple. @Value annotation is used as default message when there is no property file. We can't define localized message by it. On 2009/08/29, at 0:05, Ceki Gulcu wrote:
Takeshi Kondo wrote:
Hello Ceki I don't like to write property file(because I must execute native2ascii to property file in Japanese) , but main point is IDE support.
Because Enum and Annotation is in Java syntax, IDE inform quickly error to me in saving code. Verification approach can't check consistency on no execution. It don't utilize typed language advantage. IMO, the advantage of typed language like as Java and C# than dynamic language like as Ruby and Python is to inform error in compiling time. Japanese famous engineer Yasuo Higa have been creating excellent features from this concept. (see Tyep safe query: http://sites.google.com/site/slim3appengine/Home ). I like this concept. What do you think about IDE support?
I agree. IDE support is an important aspect of the problem.
However, I don't think developers/translators would have much patience for a verbose format. Currently, CAI18N strikes a nice balance between complexity and usability, in accordance with the Pareto principle that Yasuo Higa refers to.
IDE support would probably gel CAI18N as the i18n API of choice. I am pretty confident that one could enhance CAI18N for IDE support even if resource files are used. After all, a resource file is written in a very simple key=value "language". If an IDE plugin can support type checking for Java classes it can easily support checks for resource bundles. (If you can run, then you can surely walk.) More concretely, it all depends on the properties editor of the IDE and the extensions/hooks it supports.
Adding IDE support for CAI18N would be a very nice sub-project. I have some experience developing Eclipse plugins. Do you have IDE development experience?
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch _______________________________________________ cai18n-dev mailing list cai18n-dev@qos.ch http://qos.ch/mailman/listinfo/cai18n-dev
Takeshi Kondo wrote:
I agree. If there is IDE plugins, I'll fulfill my requirement by it. But I don't want to develop IDE plugins, because IDE plugin's maintenance is trouble-filled.
Indeed, plug-in are not easy to develop. This makes them all the more valuable. :-)
If it must need IDE's plugins, I want to make it come true, IMO.
I don't understand. What do you mean by "it" when you write "I want to make it come true" ? Also note that even today CAI18N does not need IDE support to be useful. IDE support would be nice to have but it is not necessary.
Why don't we develop simple pattern of enum + annotation as message definition?
for instance,
public enum Colors{ @Value("green") GREEN,
@Value("red") RED,
@Value("blue") BLUE }
This syntax is simple. @Value annotation is used as default message when there is no property file. We can't define localized message by it.
So if there are no resource bundles, i.e. property files, we would use the message values defined in the enum. OK but what would be the use case for that? -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
If it must need IDE's plugins, I want to make it come true, IMO.
I don't understand. What do you mean by "it" when you write "I want to make it come true" ? Excuse me for my poor English. I mean that I want to make it come true with no IDE plugins.
So if there are no resource bundles, i.e. property files, we would use the message values defined in the enum. OK but what would be the use case for that?
I suppose that this feature is useful in refactoring message id. Because Enum + Annoation is in Java syntax, we can refactoring it using IDE. And it is no need to keep consistence enum and ResourceBundle. so it is useful for developers. On 2009/08/29, at 1:24, Ceki Gulcu wrote:
Takeshi Kondo wrote:
I agree. If there is IDE plugins, I'll fulfill my requirement by it. But I don't want to develop IDE plugins, because IDE plugin's maintenance is trouble-filled.
Indeed, plug-in are not easy to develop. This makes them all the more valuable. :-)
If it must need IDE's plugins, I want to make it come true, IMO.
I don't understand. What do you mean by "it" when you write "I want to make it come true" ?
Also note that even today CAI18N does not need IDE support to be useful. IDE support would be nice to have but it is not necessary.
Why don't we develop simple pattern of enum + annotation as message definition?
for instance, public enum Colors{ @Value("green") GREEN, @Value("red") RED, @Value("blue") BLUE } This syntax is simple. @Value annotation is used as default message when there is no property file. We can't define localized message by it.
So if there are no resource bundles, i.e. property files, we would use the message values defined in the enum. OK but what would be the use case for that?
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch _______________________________________________ cai18n-dev mailing list cai18n-dev@qos.ch http://qos.ch/mailman/listinfo/cai18n-dev
participants (3)
-
Ceki Gulcu -
K2junior -
Takeshi Kondo