> ----- Original Message ----- > From: "Alon Bar-Lev" <[email protected]> > Sent: Saturday, April 20, 2013 2:54:23 PM > > > Hi! > > ----- Original Message ----- > > From: "Einav Cohen" <[email protected]> > > To: "Alon Bar-Lev" <[email protected]>, "Vojtech Szocs" > > <[email protected]>, "Alexander Wels" <[email protected]> > > Cc: "Juan Hernandez" <[email protected]>, "Yair Zaslavsky" > > <[email protected]>, "engine-devel" > > <[email protected]> > > Sent: Saturday, April 20, 2013 8:23:06 PM > > Subject: Re: Packaging and locales > > > > 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. > > Hmmm... this what I was afraid of... > > > 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. > > Oh... this what I fear... if permutation include code + locale then this is > no go for this approach. > The separate package should contain locale only, so at worse case scenario > you get locale C as default. > > Let's say going modular is too complicated for gwt based application... > however, any reason why we do not build all locales by default? For > development we can limit number of permutations, but default rpmbuild -tb > <tarball> should build all available locales.
when you are asking "why we do not build all locales by default?" I understand that you are referring specifically to an rpmbuild build, and NOT to a devel-time mvn build that a full-time ovirt-engine-GUI-maintainer performs 5 times a day, at least... so if I understood you correctly - indeed, I agree that the default "rpmbuild" should build with all available locales, assuming this is a non-frequent action, so the person performing it typically won't care if it takes some extra time, especially if it means that he will eventually gain a couple of extra available locales. > > Thanks! > Alon > > > > > ---- > > Thanks, > > Einav > > > > ----- Original Message ----- > > > From: "Alon Bar-Lev" <[email protected]> > > > To: "Vojtech Szocs" <[email protected]>, "Einav Cohen" > > > <[email protected]>, > > > "Juan Hernandez" <[email protected]>, > > > "Yair Zaslavsky" <[email protected]>, "Alexander Wels" > > > <[email protected]> > > > Cc: "engine-devel" <[email protected]> > > > 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 > > > > > > _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
