[Engine-devel] Packaging and locales

[Einav Cohen]

> ----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> Sent: Saturday, April 20, 2013 2:54:23 PM
> 
> 
> Hi!
> 
> ----- Original Message -----
> > From: "Einav Cohen" <ecohen at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>, "Vojtech Szocs"
> > <vszocs at redhat.com>, "Alexander Wels" <awels at redhat.com>
> > Cc: "Juan Hernandez" <jhernand at redhat.com>, "Yair Zaslavsky"
> > <yzaslavs at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>
> > 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" <alonbl at redhat.com>
> > > To: "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen"
> > > <ecohen at redhat.com>,
> > > "Juan Hernandez" <jhernand at redhat.com>,
> > > "Yair Zaslavsky" <yzaslavs at redhat.com>, "Alexander Wels"
> > > <awels at redhat.com>
> > > Cc: "engine-devel" <engine-devel at 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
> > > 
> > 
>