On Sat, Apr 07, 2012 at 12:17:56AM +0200, Christian Völker wrote: > Hello, > > Am 05.04.2012 um 22:21 schrieb Tim Donohue: > > > To this end, I've attempted to summarize what I've read in this thread > > into a new Proposal page on our wiki: > > > > https://wiki.duraspace.org/display/DSPACE/i18n+Improvements+Proposal > > > > The goal of this wiki page is *not* to take discussion away from this > > listserv. > > I just found this page and Id like to comment on. > > > We dont need to discuss messages.properties und messages.xml files together. > > Both types of files can not be mapped to each other because of differences > in content, not only differences in format. Thus, translating both user > interfaces is a separate effort anyway. With ongoing modularization, they > will depart from each other even more, so there is no chance to keep them > synced somehow. In the times when there was only a jspui, translation did > not seem that troublesome, so I would concentrate on the new situation > with Cocconn .xml-files. Furthermore, it was said there a tools available > for the .properties files, so one more reason, to deal with them for the > moment.
messages.properties has another problem: it's a mixture of texts used by JSPUI and texts used by dspace-api. I feel that we need to pull these apart. > Some thoughts on the messages.xml format > > .ts files for which tools exist are XML files either. With the extremly > simple structure of messages.xml catalogues it should not be that much > of a deal to create e.g. a XSLT transformation for translating back and > forth. > > The simple structure of message catalogues by itself seems limiting > however. I read over this page to get an idea of whether > xmlns:i18n="http://apache.org/cocoon/i18n/2.1 contains some more useful > attributes or such to store more info but I could not identify. I think > a translation file format should support an attribute "untranslated" or > "deprecated" for each message string at least, with an translators comment > being another desirable feature. > I havent tried to feed Cocoon with a messages.xml file that was just > extended with no regard to the schema definition, but it would be worth > to create our own messages.xml format as long as we dont break existing > functionality. I had not thought about the preferred source form for translation being enriched with attributes that are only used in the translation process. It would make sense to ship the catalogs in such a format, to support translators, and then convert it to the preferred form for runtime while packaging the applications. Maven has conventions for dealing with sources generated by the build process. Once the conversion tools have been identified, we just have to plumb them into the right build stage. We could even convert the same sources to different forms of generated-sources in different components if that seems useful. I feel that we should strongly resist any temptation to just create our own DSpace-specific format. If there is an existing one that we can agree on, we should adopt that. I feel that it is worth some effort to avoid adding to the cacophony of competing formats if we can. If we decide to augment messages.xml then the changes need to be in their own namespace (and that namespace might make a valuable contribution to the translation community beyond DSpace). Then Cocoon should not even see our additions, and anyway they'd be easy to transform out of what Cocoon is given. [snip] > For emails, it would already be an improvement if the scheme with adding > the language to the file name would be applicable. E.g. feedback and > feedback_de. > With this said, this might not work in all cases. Most emails are triggered by > user interaction in the web interface. The proper locale could be derived from > browser settings then. However, some notifications are sent just to make the > user aware of new items or such and that he should visit the site again. > In this case, the eperson record would need to store the preferred locale. > I dont know whether this is the case already. There is already a "language" column. It is a VARCHAR(64) and probably ought to be recast as some short datum that can be used by the applications for making decisions, such as locale names ("fr_CA" and the like). I don't know how it's used at the moment. > I am not sure whether it would be a good idea to turn emails into just a > single message in the catalog file. First, which of them, the jspui > .properties > or xmlui messages.xml? Or a precedence rule? Like the version associated to > the > interface in use is the one that will be read? Now, not really. What, if one > day, the jspui gets removed? There is another reason, not to put emails into > the catalog. People might want to use formatted mail. I doubt that this will > work easily within a message catalog and if only for the amount of text. Email templates belong to the dspace-api, not to any dspace-XXXui. This is another reason why we need to work out a clear understanding of which texts belong to which components and keep them close to the code which uses them. > dspace.name is not much of an issue for me personally but this might depend. > > news.xmlui, news-top and the like might be a similar case as email. > > Community and Collection description I would rank high, right behind > input-forms.xml or they might even share first place. All of these are data for which localization support would be welcome, but which cannot be translated once for all sites. I think that these are excellent candidates for tucking into the database and providing good support in the administrative UIs for localization by the individual administrator. Container descriptions and the site name can be metadata fields on those objects. I suppose that news could be too, although there are sites which want to do extensive markup of news and that might be an *interesting* combination with storage as metadata fields. -- Mark H. Wood, Lead System Programmer [email protected] Asking whether markets are efficient is like asking whether people are smart.
pgpTFf4v2bH5d.pgp
Description: PGP signature
------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
