Hello folks, Thanks for transifex scripts to initial setup a synchronization file.
Oscar, you describe the approach I've followed in the past to get the translated files back to the source pool. - have a config file that describes what to synch - translate the origin files using transifex - synch the translated languages back to the local checkout - test the translations and - commit these back to the source repository (was svn and is git) This works perfect if the user/translator has commit access for the repository (or since a few weeks : can create a pull request). I think it would be great to have a wider public crowd helping to create translations for a wider range of languages than we have right now. The cool thing is, that GeoServer already has the major languages supported - even if the coverage is quite different. IMHO administrators all over the world love it to have an interface in their native language. I'd like to suggest an other approach to separate source from translated language files. its possible to create different jars for different languages. Means that the core module can have several modules with the same name and extension for the translated properties files it provides: - core (core implementation and Message-Support inclusive the origin (en) properties files - core_it (provides only the *_it.properties files) - core_de (provides only the *_de.properties files) .. and so on IMHO we could separate the i18n projects from the GeoServer core modules/project and setup a GeoServer_i18n project which provides a common infrastructure to - synch properties files from transifex - maven modules that creates jars out of it PRO : Translators don't need commit access, the translator team could manage, whether to provide a "language pack" if GeoServer start the release process. Otherwise everybody can create language files afterwards and put the results into libs folder of the preferred app server/container. It makes sense to provide an additional download-section at geoserver.org where users can get a full packaged language "installer" or zip file created from transifex. @Developers : What do you think about separating i18n. And what about a separate infrastructure to build artifacts for i18 support. Feedback is warmly welcome! Cheers, Frank 2012/10/23 Chris Holmes <[email protected]>: > > > On Tue, Oct 23, 2012 at 6:56 AM, Oscar Fonts <[email protected]> wrote: >> >> 2012/10/22 Chris Holmes <[email protected]>: >> > Should I be able to just run that script on a geoserver checkout and >> > then >> > have it wired to the geoserver_test project? And be able to pull down >> > updates from the transifex server? I'll try it out, but just want to be >> > sure >> > that's the intention. >> >> Yes, that's the intention. >> >> > > Awesome, will try to try it out this week. > >> >> > Also what are your thoughts on bringing over some of the translations >> > from >> > the geoserver_22x transifex? I suppose we could just create those in the >> > new >> > repo and move the files over. >> >> Sure. Gave you access to geoserver_test if you want to play. >> >> I understand that the definitive place for translations will still be >> github, periodically pulling from transifex, right? >> >> > > Yup. And I'd like us to improve the GS developer docs to make pulling from > transifex as easy as possible. Perhaps try to recruit a 'localization lead' > who can pull in periodically and commit. And also let people who do > translations notify that person that they finished up a language. > >> >> >>> Regarding character encoding: >> > Really? Gabriel and I didn't successfully do this, and it looked like >> > there >> > might be some problems with how GeoServer reads them in. >> >> You are right, it works when running jetty from inside Eclipse, but >> the web-core translation file is corrupted when building with maven. >> >> After a bit of investigation, the problem is with the >> maven-antrun-plugin in web/core/pom.xml >> You have to declare the resource files encoding as ISO-8859-1. See commit: >> >> https://github.com/oscarfonts/geoserver/commit/b172716e86536ddfad8485a55eb479be8d74e58e >> > > Oh awesome. I'll try to test with Gabriel to confirm. > > >> >> -- >> Oscar. > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > Geoserver-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ GeoTools-Devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
