[ovirt-devel] [ACTION REQUESTED] i18n default English text is now stored in properties files
Yaniv Dary
ydary at redhat.com
Tue May 31 15:24:17 UTC 2016
Is this change being done for 4.0? I would think this is a risky change
that better fits 4.1.
Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109
Tel : +972 (9) 7692306
8272306
Email: ydary at redhat.com
IRC : ydary
On Tue, May 24, 2016 at 6:20 PM, Scott Dickerson <sdickers at redhat.com>
wrote:
>
>
> On Tue, May 24, 2016 at 9:28 AM, Martin Sivak <msivak at redhat.com> wrote:
>
>> > Are you talking about some files in specific, and if so which ones?
>>
>> # find . -name AppErrors.properties | grep -v generated | grep -v target
>>
>>
>> ./backend/manager/modules/dal/src/main/resources/bundles/AppErrors.properties
>>
>> ./frontend/webadmin/modules/frontend/src/main/resources/org/ovirt/engine/ui/frontend/AppErrors.properties
>>
>> ./frontend/webadmin/modules/userportal-gwtp/src/main/resources/org/ovirt/engine/ui/frontend/AppErrors.properties
>>
>> ./frontend/webadmin/modules/webadmin/src/main/resources/org/ovirt/engine/ui/frontend/AppErrors.properties
>>
>
> That properties file does appear 3 times on the frontend side. It is
> quite annoying, and there is a reason for it. I ran a process to move
> English text to properties files out of annotations, creating the
> properties files as necessary. In this case, AppErrors.properties existed
> in both "userportal-gwtp" and "webadmin", but didn't originally exist in
> the frontend module. Due to the way GWT i18n and GWT compiling work,
> default values from annotations on the interface would augment the
> properties values that GWT finds first on the classpath. Since
> AppErrors.properties in "webadmin" is closer to the compiler then
> AppError.properties in "frontend", webadmin will be used. This allows us
> to have a full set of AppErrors messages per GWT project, unique to get GWT
> project. It still confuses me a bit. There are better ways to do this.
>
> ConsoleErrors and VdsmErrors do the same thing. Those 3 message bundles
> are on the list to do something about in the next round of work. We'll
> probably create a common (App|Console|Vdsm)Errors interface, move messages
> that are the same between the user portal and the admin portal to the
> common ancestor and only define app specific keys in their respective
> projects.
>
>
>>
>> Now, I know the files are not 100% equivalent, but we were adding the
>> same messages to all of them in all the features I was working on.
>> This leads me to believe that most of the people treat them as the
>> same and we should only have one source for them.
>>
>>
> Yes, our goal is to only have 1 source for them. It is unfortunate that
> you have to add the text in multiple places currently. We'll get better
> (soon).
>
>
>>
>> Martin
>>
>> On Tue, May 24, 2016 at 3:17 PM, Scott Dickerson <sdickers at redhat.com>
>> wrote:
>> > response inline
>> >
>> > On Tue, May 24, 2016 at 5:29 AM, Martin Sivak <msivak at redhat.com>
>> wrote:
>> >>
>> >> Hi,
>> >>
>> >> We still have three almost identical files. Can we somehow keep just
>> >> one and generate the other two? I was actually playing a bit with a
>> >> change in the opposite direction - keeping just the EngineMessages
>> >> enum with added default english translations and generating all other
>> >> files from it.
>> >
>> >
>> > Are you talking about some files in specific, and if so which ones?
>> >
>> >>
>> >> Do you think it would make sense? It would not require a test then as
>> >> the consistency would be checked during compilation phase directly.
>> >
>> >
>> > Sure, generating some code from a key/message file could be useful. The
>> > difficulty comes in when we have Messages or Constants interface that
>> > inherit from a common ancestor. That construct is used a few times to
>> share
>> > messages between both the user portal and the admin portal.
>> >
>> > The primary reasons this change was done was to simplify translation
>> and to
>> > better manage workflow between language files in gerrit and documents in
>> > Zanata. With this change, there is now a 1 to 1 mapping of properties
>> files
>> > to zanata documents. Well, for the front end i18n code at least. The
>> > current translations for 4.0 can be seen here:
>> >
>> > https://translate.zanata.org/iteration/view/ovirt/master/documents
>> >
>> > We will be making additional i18n changes for 4.1, so any input is very
>> > welcome.
>> >
>> >>
>> >> Martin
>> >>
>> >> On Mon, May 23, 2016 at 7:38 PM, Scott Dickerson <sdickers at redhat.com>
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > In order to resolve bug [1] and prep [2], the default English text
>> for
>> >> > I18N
>> >> > Constants and Messages have been moved to their corresponding
>> properties
>> >> > files. Going forward, if a new constant or message needs to be
>> added,
>> >> > please add the key method to the proper interface and then add the
>> key
>> >> > plus
>> >> > English text to the interface's corresponding properties file.
>> Checks
>> >> > will
>> >> > be added, in the next few days, to fail the build process if the GWT
>> >> > annotations (@DefaultStringValue, @DefaultMessage) are used.
>> >> >
>> >> > This change has been made to simplify the translation process [1]
>> and to
>> >> > prepare for the replacement of the GWT i18n engine in 4.1 [2].
>> >> >
>> >> > For example, in the webadmin project, the ApplicationConstants [3]
>> >> > interface
>> >> > previously looked like:
>> >> > package org.ovirt.engine.ui.webadmin;
>> >> >
>> >> > import org.ovirt.engine.ui.common.CommonApplicationConstants;
>> >> >
>> >> > public interface ApplicationConstants extends
>> >> > CommonApplicationConstants
>> >> > {
>> >> >
>> >> > @DefaultStringValue("oVirt Engine Web Administration")
>> >> > String applicationTitle();
>> >> >
>> >> > @DefaultStringValue("About")
>> >> > String aboutPopupCaption();
>> >> >
>> >> > @DefaultStringValue("oVirt Engine Version:")
>> >> > String ovirtVersionAbout();
>> >> >
>> >> > Now, the interface looks like this [4]:
>> >> > package org.ovirt.engine.ui.webadmin;
>> >> >
>> >> > import org.ovirt.engine.ui.common.CommonApplicationConstants;
>> >> >
>> >> > public interface ApplicationConstants extends
>> >> > CommonApplicationConstants
>> >> > {
>> >> > String applicationTitle();
>> >> >
>> >> > String aboutPopupCaption();
>> >> >
>> >> > String ovirtVersionAbout();
>> >> >
>> >> > With a new properties file created, ApplicationContants.properties
>> [5],
>> >> > with
>> >> > this kind of content :
>> >> > #
>> >> > #
>> >> > # Bundle name: org.ovirt.engine.ui.webadmin.ApplicationConstants
>> >> > #
>> >> > #
>> >> > #Thu May 19 01:24:21 EDT 2016
>> >> > aboutPopupCaption=About
>> >> > applicationTitle=oVirt Engine Web Administration
>> >> > ovirtVersionAbout=oVirt Engine Version\:
>> >> >
>> >> > Let me know if there are any questions.
>> >> >
>> >> > Regards,
>> >> > Scott
>> >> >
>> >> > --
>> >> > Scott Dickerson
>> >> > Senior Software Engineer
>> >> > RHEV-M Engineering - UX Team
>> >> > Red Hat, Inc
>> >> >
>> >> >
>> >> > [1] - https://bugzilla.redhat.com/show_bug.cgi?id=1224423
>> >> > [2] - https://bugzilla.redhat.com/show_bug.cgi?id=1287408
>> >> > [3] -
>> >> >
>> >> >
>> https://github.com/oVirt/ovirt-engine/blob/569695916d2325d0c1e1fdabb6f85cd9e97d7232/frontend/webadmin/modules/webadmin/src/main/java/org/ovirt/engine/ui/webadmin/ApplicationConstants.java
>> >> > [4] -
>> >> >
>> >> >
>> https://github.com/oVirt/ovirt-engine/blob/master/frontend/webadmin/modules/webadmin/src/main/java/org/ovirt/engine/ui/webadmin/ApplicationConstants.java
>> >> > [5] -
>> >> >
>> >> >
>> https://github.com/oVirt/ovirt-engine/blob/master/frontend/webadmin/modules/webadmin/src/main/resources/org/ovirt/engine/ui/webadmin/ApplicationConstants.properties
>> >> >
>> >> > _______________________________________________
>> >> > Devel mailing list
>> >> > Devel at ovirt.org
>> >> > http://lists.ovirt.org/mailman/listinfo/devel
>> >
>> >
>>
>
>
>
> --
> Scott Dickerson
> Senior Software Engineer
> RHEV-M Engineering - UX Team
> Red Hat, Inc
>
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20160531/f3165265/attachment-0001.html>
More information about the Devel
mailing list