Re: [Xdoclet-user] OPEN POLL: do you want support for multiple languages in XDoclet?

[Hani Suleiman]

Actually, I'll clarify. I have far less of an objection to i18n done the common sense standard java way, using resourcebundles and simple lookups that anyone can understand. What I have a very strong objection to (besides the dubious need for i18n in the first place) is the incredibly complicated way it's done in xdoclet, and how up until very recently, building xdoclet resulted in a few unpleasant messages from the translator about missing keys (yes, I build in English too).

On Thursday, January 30, 2003, at 09:20 AM, David Ward wrote:

I vote: Yes.

And I will rebutt reasons for No mentioned earlier:

If you desperately require build messages in your native tongue and that's your barrier to entry then you have very very serious problems and should reconsider your java career

The xdoclet community is an OPEN source community. Developers and users of OPEN source come from around the world. This statement (notice I didn't say "This person") sounds very CLOSED, bordering discrimination.

Impossible to maintain

Incorrect. Many large software systems, including ones I have worked on, are I18N'd and readily maintainable.

Increases system complexity

Java makes it very easy to internationalize and localize. Using java.util.ResourceBundle is very simple to use. It has built in support to default to, say English, if a specific Locale has not been translated for yet.

Uses up valuable coding time from the core team without adding much value

Once a simple String lookup pattern is decided upon, then it's just a matter of calling that one method (with a String key) in the code instead of hardcoding an English String. How does that "use up valuable coding time?" As far as "without adding much value," see my first rebuttal.

Increases barrier to entry for casual contributors/developers

This does not make any sense. If xdoclet defaults to English, how does it possibly "increase barrier?" On the contrary, it *breaks down barriers* for the entry of non-English speakers - both developers and especially users.

Peformance: Uses up more memory/processing than just a String

In my experience (using tools like OptimizeIt!) with large, multi-lingual applications, this is not the case. On the contrary, localized Strings can be centralized in a "StringFactory" of sorts which can cache these objects in a flyweight pattern which both conserves memory and speeds up processing. If the xdoclet team would like my input on how I've implemented this pattern for I18N I would be happy to share.

David

PS: My native language is English, but I am a student of Spanish. My Linux environment and all my supporting applications (mozilla, vim, etc.) are in Spanish.



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user