On Tue, Apr 03, 2012 at 04:30:43PM +0200, helix84 wrote: > Let me start over, constructively.
I'll try to follow suit. [snip] > What I ask of you is not to deal with localization in DSpace, the > application. Don't import strings into the DSpace database. > Instead, provide the infrastructure for translators to do their work > easily. I'm asking you to do _less_ work, not more. > You are have the developer hammer in hand and the translation issue > seems like a nail to you. It's not. Actually I agree with all this. > My proposal of the infrastructure is as follows: > > 1) convert messages.xml, Messages.properties and email templates to .pot Here's where I begin to disagree, at least in the case of Messages.properties. I don't see how converting from a format understood by DSpace *and* common translation tools, to one not understood by DSpace or any other Java code that I know of, helps us. messages.xml is specific to Cocoon, so maybe just supplying an appropriate XSL transform to some other format, and some kind of program to convert back, would be simplest. And yet, surely there are other Cocoon projects that would benefit from having common tools understand its catalog format. The effort of producing a converter might best instead be spent on developing format handlers for the common tools and contributing them to those projects. I think that email templates require a bit more thought. Just for example, we might want to replace DSpace's own code with an existing templating package. At any rate I'd like to hear some more discussion before we cram them into *any* other format. > 2) pull all the message catalogs of different modules in one place > (git repo or website) > 3) give translators write access to this place > 4) optionally, push these catalogs to a web-based translation system > 5) automatically pull the translated .po files from the translators, > convert them back to localized source files (messages.xml, > Messages.properties, email templates) and push them to the official > dspace repo Most of this was just proposed over on -devel. What do you think of it? http://sourceforge.net/mailarchive/message.php?msg_id=29028526 > In more detail: > 1) gettext is a standard. There's a whole ecosystems that enables > translators to work with them easily, as they see fit. It's hard to > update a .properties or .xml file reusing previous translations. It's > easy with .po files. Java property bundles are a standard, and the ecosystems that understand gettext seem to understand them too. It would seem that in this case, ease of update is a tools problem, not a format problem, if it is a problem at all. [snip] > 2) The proliferation of independent modules is a good thing. It's only > hard to find files that need to be localized. That is something we need to fix. Anyone doing global translations should be able to refer to a well-maintained document which says, "these are all the places that you need to look." Each separable component should document its localization needs. Guides for developing in DSpace should not fail to request internationalization and suggest how to go about it. > 3) Make it easy. Make a simple git repo, with .pot files updated > daily, which would hold the .po files. Generously give write access to > this repo, there's nothing to here that would break DSpace. Reasonable, give or take my quibble about formats. > 4) Once you're using a standard format, you have access to a lot of > existing tools that work with it. Web-based translation systems are > easy to use for inexperienced translators. There's a plethora to > choose from: Pootle, Transifex, Launchpad, translationproject.org just > to mention a few. Transifex was proposed over on -devel. It understands property bundles. [snip] > You want DSpace to be easy to translate. Make it easy for translators, > give them a familiar format that they can work with with tools > familiar to them. Lower the barriers of contributing regularly by > generously giving them write access and by automating imports. Perhaps I misunderstand how the tools work. It seems to me that a translator shouldn't be seeing file formats at all underneath the tooling. The translator should be working with keys and values, and the tooling should accept and produce whatever formats are required at the beginning and end of the process. -- Mark H. Wood, Lead System Programmer [email protected] Asking whether markets are efficient is like asking whether people are smart.
pgpFITtnIDUAk.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
