Hello, I was very confused yesterday and I stay with my complaints from then although I have found out that I misconceived some aspects of the whole localization thing. The basic issue is that it is all screwed up, inconsistent and it does not behave exactly as it is described in the wiki. Also, inline comments sometimes emphasize side aspects and thus make it hard to grasp the essential information burried under it.
I was wrong in suspecting strings for common functions of JSPUI and XMLUI being taken from the JSPUI files. They are duplicated. So when dealing with XMLUI, you dont need the .properties. And localized files get fetched automatically. Why I write again, I got the impression that configuration and behaviour of the XMLUI internationalization behave different from the description in the wiki. In JSPUI, there are two aspects to configure, a list of supported languages and which of them to consider as default. In XMLUI there is only one list and no option to set the default language. The list should work in a first match fashion, similar to an ordered list. The default language should be chosen by renaming the customized language file to the name of the default file messages.xml. This is what the wiki tells. What I have found so far: If you ignore the list completely and dont specify any language, all languages where the repository contains a file for at build time will be supported and will be delivered depending on browser settings. This is what I voted for yesterday. What the list seems to do is to limit the languages supported as soon as it is defined, thus excluding any language that is not contained in the list. This might be useful, but it is not exactly the behaviour described. The default language is the part where things become tricky. As soon as you configure some Browse options, you will have to add some strings for that purpose in the files for every language you want to support. Thus, you will probably copy messages.xml to messages_en.xml in the overlay directory and add some lines. Now, as soon as there is a messages_en.xml file, the messages.xml file still gets copied to the webapps, but it will rarely be used. This is at least what happens here. If a list of supported locales is defined and the browser requests a language not in the list, the messages_en.xml file will be used instead. This makes it essentially impossible to set a different default language as soon as you modify the english locale. Things become worse if you are using a) one of the languages where a localized file is in the repostiory, b) you have to modify it, e.g. to support a customized browse configuration and c) you want it to be the default language. My example language here is german. I copied the messages_de.xml to the overlay directory, applied my modifications and renamed it to messages.de. Then, I did a mvn clean and rebuilt everything. By doing so, the original messages_de.xml file gets pulled again and will be copied to the webapps directory, because there is no overlay file with the same name. Now I have two german files, one default messages_de.xml and a customized messages.xml, but the original file misses some required strings. What I get displayed is a mix of both files. Every message already defined in the original file from the repository will be taken from there and my customization is good for nothing. Every new line gets fetched from the messages.xml. If the browser requests a language which is not available at all, it will see everything from the default messages.xml, the very look intended for the german visitor. The mix works with other languages as well, e.g. italian with a few german lines thrown in. English is fine because the is a complete modified file and there is just no other source anymore, because dspace repository does not contain a messages_en.xml. I find this behaviour less then useful. Granted, at least there is some string at all and no ugly xmlui.ArtifactBrowser.Navigation.browse_xyz gets displayed, but it remains confusing an hardly manageable. One solution to this would be to always keep two copies of the file in sync, one called messages_de.xml and the other messages.xml. This means, if I fand a typo later on I have to fix it in both files. In reality, I have to fix it in six places, because building has become such a lenghty process with maven, that I cant easily preview my results. As such, I will start in the webapps directly, the copy my changes over to the source directory to be prepared for the day when I have to build again from scratch to not loose anything then. Lastly, I will copy ma changes to the target directory to have them there in case ant update is sufficient for the changes in question. To be honest, no, this is not practical. In the end, I stay without my own language as default language and without a list of supported languages. This seems to be best. Every other configuration makes things worse. BTW, the new behaviour with config-files being copied to .new-files is a very nasty source of complications. If you do modifications there, you will have to take care anyway to not loose them. Now, you have a new source of unpredictable behaviour. You try to hunt some issue and the system does not behave as you configured it and in the end the reason was, that mvn and ant all worked fine, but your changes just did not get applied. At first glance I thought it looks nice, but no, it makes some very special way to work with the system the default way to work with it. Bye, Christian ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
