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