Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1287408

Summary:	[RFE] [CodeChange] reduce number of gwt compilation permutations by developing an alternate localization mechanism
Product:	[oVirt] ovirt-engine	Reporter:	Einav Cohen <ecohen>
Component:	Frontend.Core	Assignee:	Scott Dickerson <sdickers>
Status:	CLOSED WONTFIX	QA Contact:	Lukas Svaty <lsvaty>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	3.6.0	CC:	bugs, gshereme, sdickers
Target Milestone:	---	Keywords:	CodeChange, FutureFeature
Target Release:	---	Flags:	oourfali: ovirt-future? rule-engine: planning_ack? ecohen: devel_ack+ rule-engine: testing_ack?
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-10-10 15:35:08 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	UX	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Einav Cohen 2015-12-02 02:48:00 UTC

the number of permutation executed/generated by the gwt compilation process (as part of the overall engine build process) is determined by the number of targeted user-agents multiplied by the number of targeted locales (e.g. targeting 4 user agents and 8 locales results in 4*8 = 32 permutations). 

each permutation is targeting a specific user agent + locale combination. 

in order to reduce the overall gwt compilation time (for developers, ci, etc.), we would like to reduce the number of permutations executed by eliminating the locale "vector" of the gwt compilation permutations mechanism - we should be able to come up with an alternative for multiple-locales support without relying on the gwt built-in permutation-based one.

Comment 1 Einav Cohen 2015-12-02 02:55:25 UTC

while at it, I would like us to also:

- eliminate all text from .java files and rely solely on .properties files for (English and non-English) texts - this should simplify our translation process (which involves another system - Zanata) as well as eliminate any gwt-specific conventions/methods around localization. 

- (may be related to / a result of the above) eliminate duplicated strings being pushed today to Zanata (see bug 1224423 for more details).

Comment 2 Vojtech Szocs 2015-12-07 16:33:11 UTC

As discussed offline, this GWT i18n overhaul has following goals:

1, improve GWT compilation times (and consequently reduce system resource usage) by eliminating "locale" permutation vector -- roll our own i18n mechanism

2, improve existing UI translation process by moving default English texts from Java files into properties files (this should fix both issues mentioned in comment #1) as well as unifying Constants/Messages into single interface (less properties files to manage)

3, deploy UI texts (properties files) to Engine as WebAdmin/UserPortal resources which allows more granular i18n handling -- possible to create rpm packages for different UI locales

4, use above mentioned custom i18n mechanism for branding [1] messages too -- eliminate DynamicMessages and related infra as needed

  [1] http://www.ovirt.org/Features/Branding#Text_messages

Note #1: there is one open issue - date/time & number formatting relies on locale info so we'll need to solve this too, e.g. custom formatting functions etc.

Note #2: we should write a Java Checkstyle rule that checks all GWT frontend code and warns about the usage of any 'com.google.gwt.i18n.client.*' (standard GWT i18n infra) class.

Comment 4 Greg Sheremeta 2018-10-10 15:35:08 UTC

Unfortunately we don't have capacity to work on this.