On Tue, Apr 03, 2012 at 10:51:08AM +0200, helix84 wrote: > Pretty please, don't reinvent the wheel poorly, just give us translators > .po files (preferably one). Then there are existing tools like Pootle and a > bazillion others for things like online translation and reusing old > translations.
Too bad we can't go back to the 1990s and explain this to the people who built java.util.ResourceBundle and the people who reinvented *that* wheel in XML for Cocoon. Otherwise we'd have to reinvent a lot of what they did. Reinvention seems to be the order of the day, in internationalization of code. Others have already reinvented this wheel pretty well, and bolted it firmly into the rest of their work. If you want to work in .po format, there are tools which can convert formats. Trying to recreate gettext in Java, making it work seamlessly with the *other* I18N/L10N bits of Java (DateFormat, for example), and then grafting it all onto Cocoon sounds like a bit much, given that message translation is not what DSpace is *for*. That effort, it seems to me, would be better spent in building any missing format conversions, which can be used by lots of people in addition to DSpace sites. I note that the site mentioned in the thread over on -devel handles Java property files *and* .po files (and a number of other formats). For that matter, so does Pootle. It should be fairly simple to work in the format you like best and translate to/from the format(s) that DSpace wants. Regardless of format it all comes down to bundles of mappings of one set of keys onto multiple sets of values. I don't think it's *possible* to have One Catalog to Rule Them All. Nobody controls all of the localizable code in DSpace. DSpace is supposed to be extensible by sites who see needs that others have overlooked. And a well-made extension that gets shared will probably need a message catalog. Of its own, because it isn't developed as part of The Core. I've written tiny add-on aspects to drop into XMLUI that had their own tiny catalogs, because those messages didn't *belong* in DSpace-proper; they belong to the add-on and need to be maintained with it. Besides, the "main" catalogs already seem unwieldy large. -- Mark H. Wood, Lead System Programmer [email protected] Asking whether markets are efficient is like asking whether people are smart.
pgpOLWt3MdYk9.pgp
Description: PGP signature
------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
