Hello, it is a long time that I participated in this list and now I come back again with a rant. Sorry for that.
I just spent a bunch of hours to fiddle out which files exactly have to be localized, where to get them and where to put them fpr DSpace 1.7.2. Developers might find this all very understandable if not even logical, but from a users perspective it is barely usable. I know DSpace since 1.3 and back then one was lucky if there were localization files available for ones own language. Now there are many localizations readily available, but despite of all the translation work being done already, it has become far more complicated to benefit from it since the old days. We want to use the XMLUI in the future, so it was easy to understand that we need a different Localization file instead of Messages_de.properties and the name messages_de.xml is a natural name for the new file. Discovery is a separate feature and ok, it has got a separate localization file. This is fine for modularization reasons. Well, you are done? No, just started. JSPUI and XMLUI share some settings in dspace.cfg, so yes, the idea come to mind, that there might be a place for shared localization. When searching for the proper place to put my localization strings for the configurable browse interface, me current guess is, that I have to put these strings, such as webui.browse.item.xyz into the JSPUI Localization file. Beware before following this trail, I have not tested yet tested it. There are still more places to look at, but we will see that later. Now, with maven, directory structure has become that complex that you dont really want to tuch it manually. Yes, I have already learned the idea of overlays and the ubiqituous path snippet src/main/resources, but then it is not ubiquituous. The mechanism seems to be used in some places but not in others. Ok, when you want to work with localization, you have to go for the source distribution. Easy so far. But then, localization files dont get pulled with the mvn package command. Why that? Localization should be a users choice. So even if you apply modifications which change the meaning of some parts of DSpace, it would still be helpful if the interface could be shown in the visitors language. If I would visit a japanese repository, I would be glad to see it in german. Maybe I get something wrong then, but at least, I get a basic understanding and guidance, whereas I would be lost if japanese was the only interface language. Well, one can discuss whether it makes sense to always deliver all maybe even localizations, but at least it would make it easier to use and modify localization. In the case of Messages_de.properties, you have to pull the file separately from modules/dspace-api-lang/trunk/src/main/resources/ and put it to dspace-api/src/main/resources as a default place. If you want to write an overlay however, place it to dspace/modules/jspui/src/main/resources. I dont have the path at hand for the other files mentioned above because I picked them up the other week. But I am sure, the path are different for each of them and no, they dont follow a general scheme besides the path snippet src/main/resources. Sorry guys, this is not logical at all. Did I misunderstand something seriously? Probably. Is it my fault? I am not exactly sure about that. Well, after fiddling out all this stuff I learned in the current docs for localizing JSPUI that other files to be localized can use the naming scheme with Filename-Underscore-Locale-Dot-Extension as well. input-forms.xml, which is a longtime companion is an example for that and default.license is another one. Until now, we always replaced the original files with our versions. We had already found years ago that the naming scheme works for email templates however. So Documentation is good now in that regard. Only thing, you have to read JSPUI Docs to get help for localizing XMLUI. And then, overlay mechanism does not seem to be supported for these files. Or where should I put them? After fiddling around with all these different files, I am certainly not yet done. There is surely more to find out. Instead of moaning, I should contribute. Add to the docs. Yes, I would. However, I have got the impression that my explanations would be misleading and sometimes plain wrong. I dont feel like anybody we benefit from it. More likely that readers would get scared. So I promise I will contribute as soon as localization has become simple enough that I can understand it, which seems to be required before I can explain it to others. Bye, Christian ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
