[ovirt-devel] [Russian oVirt localization] Missing English ApplicationConstants.properties in 3.6

Vojtech Szocs vszocs at redhat.com
Wed Dec 9 16:02:14 UTC 2015



----- Original Message -----
> From: "Juliette Tux" <juliette.tux at gmail.com>
> Cc: Devel at ovirt.org
> Sent: Wednesday, December 9, 2015 4:46:34 PM
> Subject: Re: [ovirt-devel] [Russian oVirt localization] Missing English ApplicationConstants.properties in 3.6
> 
> Hello Vojtech,
> 
> > In oVirt 4.0 we'll have default properties files in place.
> > we'll modify the UI i18n implementation so that you don't need to re-build
> > Engine (re-compile GWT UI) in order to see changes you've
> done to any of properties files.
> Oh, these are really good news. Thanks a lot for your support and positive
> devs feedback!

You are welcome :-) there's a lot of space for improvement in our i18n
implementation which we didn't address yet, but we will get to it :P

> 
> Best regards,
> Julia Dronova
> 
> On 9 December 2015 at 18:35, Vojtech Szocs < vszocs at redhat.com > wrote:
> 
> 
> 
> 
> ----- Original Message -----
> > From: "Juliette Tux" < juliette.tux at gmail.com >
> > To: "Einav Cohen" < ecohen at redhat.com >
> > Cc: Devel at ovirt.org
> > Sent: Tuesday, December 8, 2015 5:46:17 PM
> > Subject: Re: [ovirt-devel] [Russian oVirt localization] Missing English
> > ApplicationConstants.properties in 3.6
> > 
> > Hi Einav,
> > Hi all,
> > 
> > > As I mentioned - these (*English* .properties files) do not exist in the
> > > oVirt source code as .properties files - but as Java files.
> > Ok i got it, but I supposed this was not intentionally since in most cases
> > proper .properties files do exist in the source code. I thought that was
> > some kind of omission or error.
> 
> Hi Juliette,
> 
> the default English texts are currently located in Java files, for example:
> 
> frontend/webadmin/modules/webadmin/src/main/java/org/ovirt/engine/ui/webadmin/ApplicationConstants.java
> 
> with values expressed via Java annotation (like DefaultStringValue):
> 
> @DefaultStringValue("oVirt Engine Web Administration")
> String applicationTitle();
> 
> This is definitely not a good practice so in oVirt 4.0 we'll put these
> default English texts into properties files as you'd normally expect,
> for example:
> 
> frontend/webadmin/modules/webadmin/src/main/resources/org/ovirt/engine/ui/webadmin/ApplicationConstants.properties
> 
> Also, we'll modify the UI i18n implementation so that you don't need
> to re-build Engine (re-compile GWT UI) in order to see changes you've
> done to any of properties files.
> 
> > 
> > > in order to create *_ru_RU.properties files, Russian translations for
> > > oVirt
> > > need to be uploaded to Zanata's 'oVirt' project first.
> > In most cases in order to create Russian properties I use prop2po and
> > po2prop
> > utilities and it takes 1 minute to create good and properly unicoded
> > translated .properties file ready to be tested in the oVirt interface. We
> > are able here to test the translations directly from oVirt in order to
> > improve the translation first before uploading to the community resources.
> > But with omitted .properties the translator's work tends to be extremely
> > hard.
> > 
> > > If you need technical assistance with uploading Russian translations (in
> > > any format) to the oVirt Zanata project
> > Well, I do not. I needed technical assistance with locating missed
> > .properties files
> 
> For now, please refer to Java files containing default English texts as
> mentioned by Einav (these currently substitute properties files you are
> looking for). In oVirt 4.0 we'll have default properties files in place.
> 
> > 
> > > were auto-generated by pulling translations from Zanata's oVirt project
> > I see. Please note that those files have non-unicode characters like, for
> > example in German: "nicht l\u00F6schen" and "\n\u2013 W\u00E4hlen Sie unter
> > \u00BBEinmal", "ausf\u00FChren\u00AB" and so on. Since I'm dealing with
> > Russian language with no Latin characters at all, the whole files will be
> > looking like that I guess. Like Japanese files:
> > "${type}\u3092${action}\u3067\u304D\u307E\u305B\u3093\u3002\u30C7\u30D5\u30A9\u30EB\u30C8\u306E
> > ${type}" This makes the local translator's work VERY hard. Ofc this is not
> > your problem and I'll be asked again to write to Zanata mailing list which
> > in this case I'll certainly do.
> > 
> > In general, t his vendor lock-in to Zanata looks very disturbing to me as a
> > Open Source translator. I've been working for years locally in Lokalize,
> > freely using the gettext and other utilities and committing my translations
> > to KDE and Gnome svn/git without any problem. Now this Zanata lock-in is
> > VERY wrong and I still hope those .properties are missing in the source
> > code
> > just because of some error.
> 
> AFAIK, we're using Zanata to help manage (lots of) i18n properties
> files which are then pulled into oVirt code base in controlled
> translation cycles, so Zanata acts as repository of translations.
> 
> > 
> > Best regards,
> > Julia Dronova
> > 
> > 
> > --
> > С уважением, Дронова Юлия
> > 
> > _______________________________________________
> > Devel mailing list
> > Devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> 
> 
> 
> --
> С уважением, Дронова Юлия
> 
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel



More information about the Devel mailing list