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: