[zanata-users] po pull is not putting translations into the directories

Thu Apr 30 06:58:43 UTC 2015

Incidentally, even without those changes, the currenty zanata-cli
distribution zip and tarball, which include all our Java dependencies
except the JVM itself, are only 17M each:

http://search.maven.org/#artifactdetails%7Corg.zanata%7Czanata-cli%7C3.6.0%7Cjar

So I think the rest of the bloat must come from Fedora packaging quirks
and extra unwanted transitive dependencies, like asking for RESTEasy and
getting Tomcat thrown in.  Or perhaps asking for maven-artifact.jar and
getting all of Maven.

On 2015-04-30 10:33, Patrick Huang wrote:
> Just FYI We are working on it (trying to reduce the size of the client). Here are just a few relevant bugzillas:
> 
> * https://bugzilla.redhat.com/show_bug.cgi?id=1171529 (this will hopefully reduce the size of RPM dependencies download by 200M) 
>     | status: done pending release
> * https://bugzilla.redhat.com/show_bug.cgi?id=1186972 (doing all the work on server side so that we can ultimately have a very thin client) 
>     | status: in progress right now
> 
> Personally I've never advocated python client ever since our dedicated python developer left the company. At one stage we even considered obsoleting the package but someone volunteered to support it. And now that person has also left the company. The best bet will be java client but there are just too many ways to get it (maven, ivy, tar ball, RPM). Each of which suits certain type of user and has pros and cons. Unfortunately this is just the way it is at the moment. We will continue to improve it and make it better.
> 
> Regards,
> Patrick Huang
> Senior Software Engineer
> Engineering - Internationalisation
> Red Hat
> 
> ----- Original Message -----
>> From: "Grant Gainey" <ggainey at redhat.com>
>> To: "Bryan Kearney" <bkearney at redhat.com>
>> Cc: "zanata-users" <zanata-users at redhat.com>
>> Sent: Wednesday, April 29, 2015 11:03:09 PM
>> Subject: Re: [zanata-users] po pull is not putting translations into	the	directories
>>
>>
>>
>> ----- Original Message -----
>>> On 04/29/2015 01:22 AM, Sean Flanigan wrote:
>>>> On 2015-04-28 23:29, Bryan Kearney wrote:
>>>>> I have a project which is project type podir. My directory is set up so
>>>>> that the pot file is in locale and the translation shoudl be in a
>>>>> subdirectory (i.e. ru/ru.po).
>>>>>
>>>>> If I execute "zanata po pull" and it puts the ru.po file in the same
>>>>> directory as the pot file (/locale/ru.po).
>>>>
>>>> That does sound like a bug in the python client, assuming that the type
>>>> has been set to podir correctly (via zanata.xml or command line).  I
>>>> can't remember, does the python client log which project type it found?
>>>>   (I'm more familiar with the Java clients like zanata-ivy.)
>>>
>>>
>>> I have opened https://bugzilla.redhat.com/show_bug.cgi?id=1217041. Is
>>> there any chance to move to a single CLI? My experience tends to be:
>>>
>>> "Me: I have issue with ivy client"
>>> "Zanata: Use Python client"
>>> <time passes>
>>> "Me: I have issue with python client"
>>> "Zanata: Use ivy client"
>>> <rinse and repeat>
>>>
>>> It seems if there were one client and folks tested the hell out of it
>>> then the user experience would improve.
>>
>> Concur.  The Java client worked for me, for XLIFF and PO.
>>
>> Of course, it comes with a bonus-maven-task, which means installing ~500Mb of
>> maven-and-dependencies, just to get the CLI tool for talking to Zanata.
>> That was exciting. But I've already bent Sean's ear on that score :)
>>
>> G
>>
>>>>> zanata-python-client-1.3.21-1.fc21.noarch
>>>>> zanata-common-3.3.0-4.fc21.noarch
>>>>> zanata-api-3.4.1-1.fc21.noarch
>>>>> zanata-client-3.6.0-1.fc21.noarch
>>>>>
>>>>> Note.. i can not use the ivy client since I am getting certificate
>>>>> errors again. is there a work around for this?
>>>>
>>>> Are you referring to certificate errors when connecting to a server with
>>>> a certificate issued by a non-public CA?
>>>>
>>>> Such an error would be similar to this:
>>>>
>>>> javax.net.ssl.SSLHandshakeException:
>>>> sun.security.validator.ValidatorException:
>>>> PKIX path building failed:
>>>> sun.security.provider.certpath.SunCertPathBuilderException:
>>>> unable to find valid certification path to requested target
>>>>
>>>>
>>>> The best and most secure solution is to install the missing CA
>>>> certificate into Java's trusted certificate store.  Something like this:
>>>>
>>>> $ keytool -keystore $keystore -storepass changeit -import -noprompt
>>>> -alias internalca -file ./internalca.crt
>>>>
>>>> - where $keystore is probably /etc/pki/java/cacerts or something like
>>>> /usr/lib/jvm/java-1.7.0/jre/lib/security/cacerts
>>>> and internalca.crt is a copy of the CA cert in PEM format.
>>>>
>>>>
>>>> The workaround is to use the command line option --disable-ssl-cert, but
>>>> of course this is much less secure.
>>>>
>>>>
>>>
>>> that was it. I should have RTFH. I am fine disabling.
>>>
>>> Thanks.
>>>
>>> --bk
>>>
>>> _______________________________________________
>>> zanata-users mailing list
>>> zanata-users at redhat.com
>>> https://www.redhat.com/mailman/listinfo/zanata-users
>>>
>>
>> --
>> Grant Gainey
>> Principal Software Engineer, Red Hat Satellite
>>
>> _______________________________________________
>> zanata-users mailing list
>> zanata-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/zanata-users
>>
> 
> _______________________________________________
> zanata-users mailing list
> zanata-users at redhat.com
> https://www.redhat.com/mailman/listinfo/zanata-users
> 

-- 
Sean Flanigan

Principal Software Engineer
Localisation Tools Engineering
Red Hat

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/zanata-users/attachments/20150430/c398f95b/attachment.sig>