Let me start over, constructively. I realize the limitations: * I know that Cocoon works with .xml and ResourceBundle with .properties internally * I know you're not going to rebuild Cocoon or any other underlying DSpace components * I know about the ongoing modularization and what it means for message catalogs
> Regardless of format it all comes down to bundles of > mappings of one set of keys onto multiple sets of values. In principle, I disagree. Think of support for plural forms or ngettext. Those cannot be emulated with such a simple mapping. But as I said, I understand the limitations and that these features won't be available. I can live with that. Let's work on from there. This is all done, I'm not asking you to change that. 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. My proposal of the infrastructure is as follows: 1) convert messages.xml, Messages.properties and email templates to .pot 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 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. There already are tools to do the work. translate-toolkit converts .properties. xml2po por po4a convert xml files. Each email template is just one string to include in the .po file. 2) The proliferation of independent modules is a good thing. It's only hard to find files that need to be localized. 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. 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. 5) You have a repository with translations in .po format. It's now easy to automate their conversion. By pushing them to the official repo, you're giving access to up-to-date translations to users. 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. Regards, ~~helix84 ------------------------------------------------------------------------------ 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
