On Tue, Aug 18, 2009 at 4:00 AM, Andrea Aime<aa...@opengeo.org> wrote: > Chris Holmes ha scritto: >> >> I think that's an awesome idea. Especially if as you translated your UI >> got updated. Maybe not in real time, but if you could do a reload. But >> even if that wasn't the case it'd still be great >> >> I think submission would be fine if it was just finding the right file and >> attaching that to a jira issue. Or submitting the diff if it's updates to >> an existing one. > > I did not look, but it should be possible to extend the resource loading > mechanism so that it picks resource files from the data directory as well. Humm... next step for me is to look at how to apply the translation at runtime, if possible.
> As for seeing the results straight away, we already have a "clear > wicket caches" link that shows up when Wicket is setup in development > mode, we can replicate the same funcionality in the i18n GUI. that might do the trick, I'm not yet sure, but will look into it. > > One thing that is not clear to me is how this will play against UI > modularization. Atm we have one i18n file per GUI module: > > find . -path "./*/src/main/java/GeoServerApplication.properties" > ./core/src/main/java/GeoServerApplication.properties > ./wcs/src/main/java/GeoServerApplication.properties > ./wfs/src/main/java/GeoServerApplication.properties > ./wms/src/main/java/GeoServerApplication.properties > ./demo/src/main/java/GeoServerApplication.properties > > And there will be another one for each new GUI module we roll out > (think the security UI, or any extension specific panel we might > want to add) > > The GUI above seems to build a single integrated file instead? The GUI shows up all the aggregate resources from the different modules, but that's for the sake of simplicity for whomever is performing the translation. The idea is then to create some sort of diff that respects the modularity. It won't be any hard, as it's just a matter of matching the keys for each .properties > Wondering if it would be possible to keep the contributed translation > modularized. I guess one can use class.getResources(...) and the > use the URLs to pick up the contents of each file and generate > a similarly named file (the url path should contain the jar name, > shouldn't it?). that's the idea. The actual problem to solve after that is how to contribute back the translation. Say the module creates the diff, how does the user send it to us the easiest way? I was thinking something as easy as a button "send to developers" or such and the module sending an email. Attaching to jira automatically would be hard, and any other thing like building a zip file and just telling the user to send it back by email would work, but just not that seamlessly. Other ideas welcome though. Cheers, Gabriel > > Anyways, if it's too hard it's definitely better to have a non > modularized translation that users can make, than no translation > at all :) > > Cheers > Andrea > > -- > Andrea Aime > OpenGeo - http://opengeo.org > Expert service straight from the developers. > -- Gabriel Roldán ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
