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. 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. It should be possible to compare two versions of a messages.xml file based on the key values only. Thus the english and a localized version could be compared to find out about the coverage of the localized version quickly. On the Mac, there is nothing similar to Altovas tools, so I know only of quite simple XML Editors and I prefer diff for now. The aforementioned way of working is not possible with diff. I am sure this is just a lack of knwoledge regarding existing tools on my side. So if anyone has suggestions on great XML Tools to check out, please tell. Scattering messages.xml files all over the file tree is not much of an issue. Inconsistency in using overlays is. Hugh, did I say that? Well, as soon as one knows, that there are several places where messages.xml files go, as long as they are named exactly the same, it is one simple search to find them all. However, using overlays does not seem to be handled consitently for all modules. For now, I have learned that the proper path to put them starts with dspace/config/modules and ends with src/main/webapp/i18n/ For xmlui, the missing middle part is just "xmlui". Remember, as an user, I dont have to drop the file just into the right place, but I have to create the path. This requires better understanding. Now, eqipped with this knowledge, I try to derive the proper overlay path for modules from their source path: dspace-xmlui/dspace-xmlui-webapp /src/main/webapp /i18n dspace-xmlui/dspace-xmlui-api /src/main/resources/aspects/XMLWorkflow /i18n dspace-discovery/dspace-discovery-xmlui-api /src/main/resources/aspects/Discovery /i18n Well, "dspace-xmlui/dspace-xmlui-webapp" gets shortened to "xmlui". Should "dspace-xmlui/dspace-xmlui-api" be shortened to the same "xmlui", given that the first part of the path minus "dspace-" is the same? Or will there be a future name-clash? And for "dspace-discovery/dspace-discovery-xmlui-api" is it simply "discovery" then? Ok, then for the second part: It looks as if they cant all be thrown into "src/main/resources/i18n", also not into "src/main/resources/i18n/$modulename/". I could not even figure out whether overlays need to be supported actively by the programmer, reading files from a place agreed upon, or are they picked up by the maven process automagically? Finally, I just put them in the source path which means I compromise on the build process. Not that much of a deal for now, but you should be aware of the consequences of not explaining the mechanics from a users perspective. To sum up, a separate section "Localization" under "Customization" would be a wellcome addition as a one stop to gather this kind of information. Alter- natively, there should be a minimum documentation requirement for all new modules to mention this kind of stuff in a standardized place. Whose convenience counts most? In this thread, programmers versus localizers convenience was discussed. But localizers are still more engaged and experienced users then just users. Localizers decide when to spent the effort. Users might feel forced to upgrade their installation and the process should be made most convenient to them. It keeps support effort lower when most users use the current version. And if any pontential user finds a DSpace repository, he will make his judgement about the system based on such an instance he knows. It should be likely that it is a current one. Upgrading should not be discouraged by a complicated upgrade process as it is right now. My staging server is running 1.8, but my productive server is still 1.4. I usually can manage to spent some 50 hours on DSpace every half a year or so. This has never been sufficient to migrate my productive instal- lation to the current version. When I pick up again, then there is a new version available and it does not make much sense to deploy an intermediate version. So I start over with the current version. I have spent time to apply our customizations for 1.6, 1.7 and 1.8 on my staging machine, but never came to the point where I was able to deploy the new version. Do you understand how discouraging this is? To come back to localization, multiple files in various places are not overly convenient, but totally acceptable. But surprises such as the strings in the curate.cfg are a real issue. input-forms.xml hurts most. Of all the various files mentioned I would suggest to create an ordered list of importance. It seems that they cant be all fixed at once. The reason being, that there are different mechanisms of how they are used within the software. 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. 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. 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. Ok, this is enough for now (but probably not exhaustive). Bye, Christian ------------------------------------------------------------------------------ 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
