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.
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).
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.
Unfortunately we don't have capacity to work on this.