Re: [ovirt-devel] [ACTION REQUESTED] i18n default English text is now stored in properties files

[Vojtech Szocs]

- Original Message -
> From: "Yaniv Dary" <yd...@redhat.com>
> To: "Scott Dickerson" <sdick...@redhat.com>
> Cc: "engine-de...@ovirt.org" <devel@ovirt.org>
> Sent: Tuesday, May 31, 2016 5:24:17 PM
> Subject: Re: [ovirt-devel] [ACTION REQUESTED] i18n default English text is 
> now stored in properties files
> 
> Is this change being done for 4.0? I would think this is a risky change that
> better fits 4.1.

The follow-up changes mentioned by Scott (custom GWT i18n infra,
reduce redundancy within multiple AppErrors etc. properties files)
are planned to be done in 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: yd...@redhat.com IRC : ydary
> 
> On Tue, May 24, 2016 at 6:20 PM, Scott Dickerson < sdick...@redhat.com >
> wrote:
> 
> 
> 
> 
> 
> On Tue, May 24, 2016 at 9:28 AM, Martin Sivak < msi...@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 < sdick...@redhat.com >
> wrote:
> > response inline
> > 
> > On Tue, May 24, 2016 at 5:29 AM, Martin Sivak < msi...@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 langua

Re: [ovirt-devel] [ACTION REQUESTED] i18n default English text is now stored in properties files

[Yaniv Dary]

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: yd...@redhat.com
IRC : ydary


On Tue, May 24, 2016 at 6:20 PM, Scott Dickerson 
wrote:

>
>
> On Tue, May 24, 2016 at 9:28 AM, Martin Sivak  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 
>> wrote:
>> > response inline
>> >
>> > On Tue, May 24, 2016 at 5:29 AM, Martin Sivak 
>> 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 
>> >> 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
>> >> > 

Re: [ovirt-devel] [ACTION REQUESTED] i18n default English text is now stored in properties files

[Scott Dickerson]

On Tue, May 24, 2016 at 9:28 AM, Martin Sivak  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 
> wrote:
> > response inline
> >
> > On Tue, May 24, 2016 at 5:29 AM, Martin Sivak  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 
> >> 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 

Re: [ovirt-devel] [ACTION REQUESTED] i18n default English text is now stored in properties files

[Martin Sivak]

> 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


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.


Martin

On Tue, May 24, 2016 at 3:17 PM, Scott Dickerson  wrote:
> response inline
>
> On Tue, May 24, 2016 at 5:29 AM, Martin Sivak  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 
>> 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] -
>> >
>> > 

Re: [ovirt-devel] [ACTION REQUESTED] i18n default English text is now stored in properties files

[Scott Dickerson]

response inline

On Tue, May 24, 2016 at 5:29 AM, Martin Sivak  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 
> 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@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ACTION REQUESTED] i18n default English text is now stored in properties files

[Martin Sivak]

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.

Do you think it would make sense? It would not require a test then as
the consistency would be checked during compilation phase directly.

Martin

On Mon, May 23, 2016 at 7:38 PM, Scott Dickerson  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@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] [ACTION REQUESTED] i18n default English text is now stored in properties files

[Scott Dickerson]

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@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel