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

[Grant Gainey]

----- 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