I understand that as a developer, you don't want to involve any unnecessary transformations to other formats. KISS.
Basically, there are two groups of translators: those who prefer to work with web-based translation systems and those who prefer to work directly with files. Both have good reasons. Let's call them web translators and file translators. (I happen to be the latter.) If you want to keep different formats, it would be transparent to web translators (assuming the web translation system understands the format). It would however be more complicated for file translators. This is in fact status quo. In particular, my biggest concern is that I don't know about a tool which would properly let you update .properties files with reusing previous translations as fuzzy. Part of the problem here is that .properties files do not recognize fuzzy strings, although this could be bolted on somehow, perhaps in form of comments. (What I usually do is either convert .properties to .po files - which is a very roundabout way of doing it; or I do a 3-way merge - which probably no other sane translator does) You mentioned that Cocoon's XML format is not the only option, I didn't know that. OTOH, I didn't mention, that while gettext is the most prominent, there are also other well supported formats - XLIFF and Qt .ts files - which happen to be XML-based. Perhaps XLIFF could be used in place of Cocoon's XML; as an advantage it has proper fuzzy strings support. You suggested that instead of a localization repo, the locations of all localizable files should be just mentioned in documentation. I agree that's a solution to part of the problem, but again, that preserves status quo and doesn't make it easy to contribute back regularly. It's easier for translators to do their work in a web interface (and do no other steps) or just commit their work than to submit a patch and wait for it to be commited. Believe me, I know, I do it all the time. Imagine your productivity as a developer if you had to submit your every patch via the tracker. Yes, it is possible to do so, but productivity will suffer and you're being treated as a second-class citizen. Do you want to treat translators as first-class citizens? You may be rewarded with better translations. I forgot to speak about one more concern that Christian raised - local overriding. There should be a way of having content localized into your language and then override it with customizations for your institution. I.e., for each catalog there should be fallback in the following order: English file, localized file, localized file for my installation. (You also get fallback with Gettext for free.) As you can see, although you can see translation as assigning value to a key, there are many more concerns like overriding, plural handling, fuzzy matching and certainly others even I didn't think about. (That's why I started with venting my frustration about reinventing the wheel.) I agree with you that dspace.name would be better off in a catalog if proper catalog overriding is in place. Regarding community and collection descriptions, I disagree. This is content rather than interface and should be treated inside DSpace. See the issue I filed: https://jira.duraspace.org/browse/DS-1134 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
