Hi Alon, The available languages of oVirt's gwt-based portals are determined during compilation time. for run-time optimization purposes, the gwt-compiler executes a compilation-permutation per browser + per language. I assume that we can construct separate ovirt-engine[-*] packages, each one contains the gwt-based portals that were compiled only with the relevant locales (permutations). if we will do that, we won't be able to maintain all locales within the same web-application anymore (currently, the web-admin is a single web-application that supports all locales, same goes for the user-portal) - doing a separate web-application per locale probably makes more sense. also: could be trivial to do, but need to keep in mind that for every code-change, we will need to issue an update for each one of the ovirt-engine[-*] packages, and somehow make sure that the user will "yum update" *all* packages that he originally "yum install"ed, in order to avoid applications in different locales going out-of-sync. ---- Thanks, Einav ----- Original Message -----
From: "Alon Bar-Lev" <alonbl@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com>, "Einav Cohen" <ecohen@redhat.com>, "Juan Hernandez" <jhernand@redhat.com>, "Yair Zaslavsky" <yzaslavs@redhat.com>, "Alexander Wels" <awels@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Saturday, April 20, 2013 3:44:15 AM Subject: Packaging and locales
Hello,
From recent thread I learned that we package locales within our main package, message bundles are going into jars, and by default we do not build them all.
As this is GWT specific as far as I see in build, I have no real visibility of what happening.
However, I do expect locales to be packaged and installed as separate packages, side by side with main package.
Something like: # yum install ovirt-engine - provides en_US # yum install ovirt-engine-locale-zh_CN - will add zh_CN support.
This ease maintenance, as these translations can be maintain using their own release cycle and even out of main tree.
Any thoughts? Alon