From messages-noreply at linkedin.com Tue Aug 9 08:44:57 2011
From: messages-noreply at linkedin.com (Brian Klebash (Linkedin Groups))
Date: Tue, 9 Aug 2011 08:44:57 +0000 (UTC)
Subject: [zanata-devel] Brian Klebash invites you to join Commercial Real
Estate Data Center Networking Group on LinkedIn
Message-ID: <1187438229.7572592.1312879497131.JavaMail.app@ela4-app0128.prod>
LinkedIn
------------
From: Brian Klebash
Date: 8/09/2011
Subject: Brian Klebash invites you to join Commercial Real Estate Data Center Networking Group on LinkedIn
Brian Klebash wrote:
I would like to invite you to join my group on LinkedIn.
-Brian
I don't want to receive these messages: http://www.linkedin.com/e/-qi7649-gr4mjzca-4y/T8iSr_RfP99SGe3uLmpyqzOfi9fBTVmdhhDr/blk/I1301105585_1/tD9MbOYWrSlI/prv/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jni at redhat.com Wed Aug 24 05:22:50 2011
From: jni at redhat.com (James Ni)
Date: Wed, 24 Aug 2011 01:22:50 -0400 (EDT)
Subject: [zanata-devel] release version 1.3.0 of zanata-python-client
In-Reply-To: <1329089470.904354.1314155501923.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com>
Message-ID: <1774632665.905322.1314163370879.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com>
Hi
I just make a new package for zanata python client, version 1.3.0, for RHEL 5, 6, Fedora 14 and Fedora 15. You can find them on koji or using yum install to install it.
If you are interested in source code, please download source code from github: https://github.com/zanata/zanata-python-client, please note that the source code on my personal repo: https://github.com/jamesni is old and may not update frequently.
The main improvement for 1.3.0:
-Add support for import and export fuzzy entry
-Add python-httplib2-0.4.0-5.el6 requirement, since python-httplib2 have some issues with python 2.6 on RHEL 6
-Change project type to gettext for software and podir for publican
-Add --version and -V options to display python client version
There are some features will be implemented in the next release soon:
--msgctxt support
python client doesn't support it in current version and server also doesn't store the msgctxt
--locale mapping
we will try to add locale mapping in zanata.xml or processing it on server side.
--project type
This info will include in zanata.xml
--glossary support
We will use python client to push glossary to server
If you have any concerns or issues about the python client, please send to me or send to zanata-list at redhat.com and zanata-users at redhat.com
You can also find me (nickname: jni) on #l10n channel on IRC. Thanks.
Best Regards
James Ni
From mospina at redhat.com Thu Aug 25 00:47:27 2011
From: mospina at redhat.com (Manuel Ospina)
Date: Wed, 24 Aug 2011 20:47:27 -0400 (EDT)
Subject: [zanata-devel] release version 1.3.0 of zanata-python-client
In-Reply-To: <1774632665.905322.1314163370879.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com>
Message-ID: <511318553.923024.1314233247805.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com>
Hello James,
Thank you for the new release. I tried to update the package but it seems it's not in the repositories yet. Can you please send me the URL of koji where I can get the RPM?
Regards,
Manuel
----- Original Message -----
From: "James Ni"
To: "zanata-list" , "Manuel Eduardo Ospina Sarmiento" , "Yu Shao" , "Sean Flanigan" , "Jens-Ulrik Petersen" , "Yi Chen, Ding"
Cc: "zanata-users" , "zanata-devel"
Sent: Wednesday, August 24, 2011 3:22:50 PM
Subject: release version 1.3.0 of zanata-python-client
Hi
I just make a new package for zanata python client, version 1.3.0, for RHEL 5, 6, Fedora 14 and Fedora 15. You can find them on koji or using yum install to install it.
If you are interested in source code, please download source code from github: https://github.com/zanata/zanata-python-client, please note that the source code on my personal repo: https://github.com/jamesni is old and may not update frequently.
The main improvement for 1.3.0:
-Add support for import and export fuzzy entry
-Add python-httplib2-0.4.0-5.el6 requirement, since python-httplib2 have some issues with python 2.6 on RHEL 6
-Change project type to gettext for software and podir for publican
-Add --version and -V options to display python client version
There are some features will be implemented in the next release soon:
--msgctxt support
python client doesn't support it in current version and server also doesn't store the msgctxt
--locale mapping
we will try to add locale mapping in zanata.xml or processing it on server side.
--project type
This info will include in zanata.xml
--glossary support
We will use python client to push glossary to server
If you have any concerns or issues about the python client, please send to me or send to zanata-list at redhat.com and zanata-users at redhat.com
You can also find me (nickname: jni) on #l10n channel on IRC. Thanks.
Best Regards
James Ni
--
Manuel Ospina
Supervisor, Localization Services
Red Hat Asia-Pacific
Phone: +61 7 3514 8112
From sflaniga at redhat.com Thu Aug 25 03:19:09 2011
From: sflaniga at redhat.com (Sean Flanigan)
Date: Thu, 25 Aug 2011 13:19:09 +1000
Subject: [zanata-devel] [zanata-users] release version 1.3.0 of
zanata-python-client
In-Reply-To: <977907750.1273434.1314241619268.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
References: <977907750.1273434.1314241619268.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <4E55BF2D.1080701@redhat.com>
On 08/25/2011 01:06 PM, Jens Petersen wrote:
> Hi James,
>
>> Do you think we need commit python client bug as Fedora product? or we
>> still commit it as Zanata product?
>
> I think Fedora users who don't know "better" will report bugs
> against zanata-python-client under the Fedora product in Bugzilla.
> In fact I was surprised not to find any bugs there... ;)
>
> Asking people to use the Zanata product to search and report bugs for
> a Fedora package is unintuitive and more work for them.
> Currently the user-base may be contained/educated enough for this to work
> but this will change when more general users pick up the package...
>
> Strictly the Zanata product is for upstream and that is ok too for the server-side service
> I guess - for the python client package I feel using the Fedora product is more natural.
>
> That's my 2 yen anyway...
>
> Jens
If you're reporting a bug against a released version of the fedora
package zanata-python-client, (or rawhide, I suppose), you *should* use
zanata-python-client under the Fedora product.
Sometimes the fix is just to release a new version of the package,
because it's fixed upstream in git, or it's a dependency problem. In
other cases, we should create a second, upstream bug against the Zanata
product, so that we can schedule it for a sprint, and make use of the
custom fields in Bugzilla.
However, if you're running the client directly from git, you should
report against the upstream Zanata product. That way, bugs which are
found by the development team (for instance) before release don't clog
up the Fedora package.
--
Sean Flanigan
Senior Software Engineer
Engineering - Internationalisation
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 554 bytes
Desc: OpenPGP digital signature
URL:
From sflaniga at redhat.com Thu Aug 25 23:45:25 2011
From: sflaniga at redhat.com (Sean Flanigan)
Date: Fri, 26 Aug 2011 09:45:25 +1000
Subject: [zanata-devel] glossary push works for python client
In-Reply-To: <631859247.932407.1314280434752.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com>
References: <631859247.932407.1314280434752.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com>
Message-ID: <4E56DE95.5030409@redhat.com>
(cc-ing zanata-devel at redhat.com)
On 08/25/2011 11:53 PM, James Ni wrote:
> Hi, Alex, Sean
>
> I added MediaType.APPLICATION_JSON in @Consumes of PUT method of
> glossary service on server side, since i always use
> "application/json" as Content-Type on client side. After that, i can
> push glossary to server successfully.
Great!
Have you tried GET /glossary (via wget) to see what it looks like?
> The command for pushing glossary is "zanata glossary push
> GLOSSARY_POFILE --lang=language". currently, only one glossary file
> (under current path) for one language can push to server side. If you
> want to push several glossary files with different languages to
> server side, i don't have a good solution for that.
"zanata glossary push": good, it makes sense to have a subcommand
"glossary".
Alex, for consistency, I think we should call the maven goal something
similar: eg mvn zanata:glossary-push, rather than zanata:push-glossary.
For the Maven client, we thought about auto-detecting the locale of the
PO file, but it would be tricky to get right in all cases.
James, I assume you can call zanata glossary push a second time from the
same directory, if you want to push a different language?
CSV is the current plan for pushing multiple languages at once.
This is Google's description of their CSV format:
http://translate.google.com/support/toolkit/bin/answer.py?answer=147854
For Maven, we plan to convert 'pos' and 'description' to comments. I
suggest making 'description' the first comment, and 'pos' the second
comment, because 'description' is usually more interesting.
> There also some other issues i think maybe you could give me some
> advice:
> 1)zanata.xml
> Currently, i still use zanata.xml to get URL address, i am not sure
> if it is proper to use project configuration file for glossary
> pushing. Otherwise, user have to use --url option every time pushing
> glossary to server.
Okay, that's fine. As long as we don't make 'project' and
'project-version' required. We might make zanata.xml optional at some
point for glossary push, as long as the user supplies --url.
> Also, in the zanata.xml, there is locale mapping
> info which is needed for pushing glossary.
Good point.
> 2)How to specify glossary file name
> If user want to push Chinese, German and other language glossary
> files to server at same time, then how do we specify the glossary
> file name?
At this stage, we will only push multiple languages when using CSV.
> Do we require that glossary file name must include the
> locale name, like zh_CN.po, and de_DE.po? similar to software
> project?
Yes, I think that would be a reasonable requirement when pushing
multiple POs at once, if and when we implement that.
> Then we can use --lang=zh_CN,de_DE to pushing glossary for
> different language at same time. What do you think?
When it comes to this, I'd rather just let the user specify the PO
filenames. That way this would work:
zanata glossary push *.po
--
Sean Flanigan
Senior Software Engineer
Engineering - Internationalisation
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 554 bytes
Desc: OpenPGP digital signature
URL:
From jni at redhat.com Fri Aug 26 02:11:30 2011
From: jni at redhat.com (James Ni)
Date: Thu, 25 Aug 2011 22:11:30 -0400 (EDT)
Subject: [zanata-devel] glossary push works for python client
In-Reply-To: <4E56DE95.5030409@redhat.com>
Message-ID: <1767888640.944633.1314324690390.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com>
----- Original Message -----
> (cc-ing zanata-devel at redhat.com)
>
>
>
> On 08/25/2011 11:53 PM, James Ni wrote:
> > Hi, Alex, Sean
> >
> > I added MediaType.APPLICATION_JSON in @Consumes of PUT method of
> > glossary service on server side, since i always use
> > "application/json" as Content-Type on client side. After that, i can
> > push glossary to server successfully.
>
> Great!
>
> Have you tried GET /glossary (via wget) to see what it looks like?
Yeah, i can use wget to get a xml format content from server:
?
CN
........
Do you want to add a command to python client to retrieve the glossary from server? I have not add such command yet.
> > The command for pushing glossary is "zanata glossary push
> > GLOSSARY_POFILE --lang=language". currently, only one glossary file
> > (under current path) for one language can push to server side. If
> > you
> > want to push several glossary files with different languages to
> > server side, i don't have a good solution for that.
>
> "zanata glossary push": good, it makes sense to have a subcommand
> "glossary".
>
> Alex, for consistency, I think we should call the maven goal something
> similar: eg mvn zanata:glossary-push, rather than
> zanata:push-glossary.
>
> For the Maven client, we thought about auto-detecting the locale of
> the
> PO file, but it would be tricky to get right in all cases.
>
> James, I assume you can call zanata glossary push a second time from
> the
> same directory, if you want to push a different language?
Yes, i can call 'zanata glossary push' a second time from the same directory when pushing a different language, currently i push zh-CN and zh-TW for testing
> CSV is the current plan for pushing multiple languages at once.
>
> This is Google's description of their CSV format:
> http://translate.google.com/support/toolkit/bin/answer.py?answer=147854
>
> For Maven, we plan to convert 'pos' and 'description' to comments. I
> suggest making 'description' the first comment, and 'pos' the second
> comment, because 'description' is usually more interesting.
>
OK, I will look through if i can use python to convert CSV format to JSON.
> > There also some other issues i think maybe you could give me some
> > advice:
> > 1)zanata.xml
> > Currently, i still use zanata.xml to get URL address, i am not sure
> > if it is proper to use project configuration file for glossary
> > pushing. Otherwise, user have to use --url option every time pushing
> > glossary to server.
>
> Okay, that's fine. As long as we don't make 'project' and
> 'project-version' required. We might make zanata.xml optional at some
> point for glossary push, as long as the user supplies --url.
>
> > Also, in the zanata.xml, there is locale mapping
> > info which is needed for pushing glossary.
>
> Good point.
>
> > 2)How to specify glossary file name
> > If user want to push Chinese, German and other language glossary
> > files to server at same time, then how do we specify the glossary
> > file name?
>
> At this stage, we will only push multiple languages when using CSV.
>
> > Do we require that glossary file name must include the
> > locale name, like zh_CN.po, and de_DE.po? similar to software
> > project?
>
> Yes, I think that would be a reasonable requirement when pushing
> multiple POs at once, if and when we implement that.
>
> > Then we can use --lang=zh_CN,de_DE to pushing glossary for
> > different language at same time. What do you think?
>
> When it comes to this, I'd rather just let the user specify the PO
> filenames. That way this would work:
> zanata glossary push *.po
Ok, so you mean we extract the locale name from po file name and don't use --lang option to specify the locale?
> --
> Sean Flanigan
>
> Senior Software Engineer
> Engineering - Internationalisation
> Red Hat
From sflaniga at redhat.com Fri Aug 26 02:58:03 2011
From: sflaniga at redhat.com (Sean Flanigan)
Date: Fri, 26 Aug 2011 12:58:03 +1000
Subject: [zanata-devel] glossary push works for python client
In-Reply-To: <1767888640.944633.1314324690390.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com>
References: <1767888640.944633.1314324690390.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com>
Message-ID: <4E570BBB.2040801@redhat.com>
On 08/26/2011 12:11 PM, James Ni wrote:
> ----- Original Message -----
>> (cc-ing zanata-devel at redhat.com)
>>
>>
>>
>> On 08/25/2011 11:53 PM, James Ni wrote:
>>> Hi, Alex, Sean
>>>
>>> I added MediaType.APPLICATION_JSON in @Consumes of PUT method of
>>> glossary service on server side, since i always use
>>> "application/json" as Content-Type on client side. After that, i can
>>> push glossary to server successfully.
>>
>> Great!
>>
>> Have you tried GET /glossary (via wget) to see what it looks like?
>
> Yeah, i can use wget to get a xml format content from server:
>
>
>
>
>
> ?
>
>
> CN
>
>
>
> ........
>
>
>
> Do you want to add a command to python client to retrieve the
> glossary
from server? I have not add such command yet.
Only if it helps with your testing, it's not required at this stage. I
think wget should be enough for your testing.
Note that the XML element names will be changing, to something like this:
Tag: title
RPM
>>> The command for pushing glossary is "zanata glossary push
>>> GLOSSARY_POFILE --lang=language". currently, only one glossary file
>>> (under current path) for one language can push to server side. If
>>> you
>>> want to push several glossary files with different languages to
>>> server side, i don't have a good solution for that.
>>
>> "zanata glossary push": good, it makes sense to have a subcommand
>> "glossary".
>>
>> Alex, for consistency, I think we should call the maven goal something
>> similar: eg mvn zanata:glossary-push, rather than
>> zanata:push-glossary.
>>
>> For the Maven client, we thought about auto-detecting the locale of
>> the
>> PO file, but it would be tricky to get right in all cases.
>>
>> James, I assume you can call zanata glossary push a second time from
>> the
>> same directory, if you want to push a different language?
>
> Yes, i can call 'zanata glossary push' a second time from the same
directory when pushing a different language, currently i push zh-CN and
zh-TW for testing
>
Okay.
>> CSV is the current plan for pushing multiple languages at once.
>>
>> This is Google's description of their CSV format:
>> http://translate.google.com/support/toolkit/bin/answer.py?answer=147854
>>
>> For Maven, we plan to convert 'pos' and 'description' to comments. I
>> suggest making 'description' the first comment, and 'pos' the second
>> comment, because 'description' is usually more interesting.
>>
>
> OK, I will look through if i can use python to convert CSV format to JSON.
Okay, note that we should apply locale mappings from zanata.xml when
converting the locale IDs given column headings to server-side locale IDs.
so if the CSV looks like this:
"en","es-ES","pos","description"
"account","cuenta","noun","A user's account"
and zanata.xml has:
es
then "cuenta" should be pushed with the locale ID "es", not "es-ES".
We should do the same thing when pushing .po files: if the user says
--lang=es-ES, we would map it to "es" based on the
>>> There also some other issues i think maybe you could give me some
>>> advice:
>>> 1)zanata.xml
>>> Currently, i still use zanata.xml to get URL address, i am not sure
>>> if it is proper to use project configuration file for glossary
>>> pushing. Otherwise, user have to use --url option every time pushing
>>> glossary to server.
>>
>> Okay, that's fine. As long as we don't make 'project' and
>> 'project-version' required. We might make zanata.xml optional at some
>> point for glossary push, as long as the user supplies --url.
>>
>>> Also, in the zanata.xml, there is locale mapping
>>> info which is needed for pushing glossary.
>>
>> Good point.
>>
>>> 2)How to specify glossary file name
>>> If user want to push Chinese, German and other language glossary
>>> files to server at same time, then how do we specify the glossary
>>> file name?
>>
>> At this stage, we will only push multiple languages when using CSV.
>>
>>> Do we require that glossary file name must include the
>>> locale name, like zh_CN.po, and de_DE.po? similar to software
>>> project?
>>
>> Yes, I think that would be a reasonable requirement when pushing
>> multiple POs at once, if and when we implement that.
>>
>>> Then we can use --lang=zh_CN,de_DE to pushing glossary for
>>> different language at same time. What do you think?
>>
>> When it comes to this, I'd rather just let the user specify the PO
>> filenames. That way this would work:
>> zanata glossary push *.po
>
> Ok, so you mean we extract the locale name from po file name and
> don't use --lang option to specify the locale?
Yes, but we won't be implementing this feature at this stage. (It won't
work for FUEL, because they have filenames like FUEL_pa.po instead of
pa.po.)
--
Sean Flanigan
Senior Software Engineer
Engineering - Internationalisation
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 554 bytes
Desc: OpenPGP digital signature
URL: