From nghia.duong at crossknowledge.com Wed Sep 4 12:44:01 2013 From: nghia.duong at crossknowledge.com (Nghia Duong) Date: Wed, 4 Sep 2013 14:44:01 +0200 Subject: [zanata-users] Change default listening address and port Message-ID: Hi all, I am trying to deploy the Zanata 3.0.2 standalone server that I downloaded as a .zip from the official page. Everything seems to work fine so far, except that Zanata (or the JBoss server) listens on 127.0.0.1:8080 by default. Hence it is impossible to access the web application from elsewhere than from the host computer itself. While greping around, I found that the address was hard-coded in more than one configuration files domain.xml, host.xml, host-master.xml, host-slave.xml (all in the domain/configuration folder). My question is: is there a clean way (= a configuration option only to be modified once) to change the default address on which the server listens? I am already hosting a Zanata 3.0.0 development snapshot and it seems to "know" the right address to listen on so that the web application can be accessed from outside. But since the folder structures has obviously changed a lot, I can't find where this option was set in Zanata 3.0.0. Thanks in advance, Nghia -------------- next part -------------- An HTML attachment was scrubbed... URL: From camunoz at redhat.com Wed Sep 4 22:38:27 2013 From: camunoz at redhat.com (Carlos A. Munoz) Date: Thu, 05 Sep 2013 08:38:27 +1000 Subject: [zanata-users] Change default listening address and port In-Reply-To: References: Message-ID: <1378334307.15227.7.camel@localhost.localdomain> Hi Nghia, Thanks for the feedback. To correct this issue, you can edit the following file: JBOSS_HOME/standalone/configuration/standalone.xml Near the end of the file you'll find the section. Edit the interfaces named "public" and "unsecure", which contain the following value and change it to this: Restart the JBoss instance and your Zanata server should be accessible from the outside world. We'll make sure that is corrected for the next release. Regards, Carlos A Munoz Red Hat On Wed, 2013-09-04 at 14:44 +0200, Nghia Duong wrote: > Hi all, > > > I am trying to deploy the Zanata 3.0.2 standalone server that I > downloaded as a .zip from the official page. > > > Everything seems to work fine so far, except that Zanata (or the JBoss > server) listens on 127.0.0.1:8080 by default. Hence it is impossible > to access the web application from elsewhere than from the host > computer itself. > > > While greping around, I found that the address was hard-coded in more > than one configuration files domain.xml, host.xml, host-master.xml, > host-slave.xml (all in the domain/configuration folder). > > > My question is: is there a clean way (= a configuration option only to > be modified once) to change the default address on which the server > listens? > > > I am already hosting a Zanata 3.0.0 development snapshot and it seems > to "know" the right address to listen on so that the web application > can be accessed from outside. But since the folder structures has > obviously changed a lot, I can't find where this option was set in > Zanata 3.0.0. > > > > > Thanks in advance, > > > Nghia > _______________________________________________ > zanata-users mailing list > zanata-users at redhat.com > https://www.redhat.com/mailman/listinfo/zanata-users From nghia.duong at crossknowledge.com Thu Sep 5 15:11:59 2013 From: nghia.duong at crossknowledge.com (Nghia Duong) Date: Thu, 5 Sep 2013 17:11:59 +0200 Subject: [zanata-users] Rest API Documentation down? Message-ID: Hi all, I just wanted to point out that the REST API Documentation ( https://zanata.ci.cloudbees.com/job/zanata-site/site/zanata-war/apidocs/index.html) has been down since quite some time. I'm using that API on Zanta 3.0.2 and would like to know whether there has been any changes to it, especially around regarding timeouts (I'm trying to upload a POT file a a source document and I always get a 500 internal error). Has the documentation been moved to somewhere else? Thanks, Nghia -------------- next part -------------- An HTML attachment was scrubbed... URL: From nghia.duong at crossknowledge.com Thu Sep 5 15:12:24 2013 From: nghia.duong at crossknowledge.com (Nghia Duong) Date: Thu, 5 Sep 2013 17:12:24 +0200 Subject: [zanata-users] Change default listening address and port In-Reply-To: <1378334307.15227.7.camel@localhost.localdomain> References: <1378334307.15227.7.camel@localhost.localdomain> Message-ID: Thank you Carlos, the problem has been solved. 2013/9/5 Carlos A. Munoz > Hi Nghia, > > Thanks for the feedback. > > To correct this issue, you can edit the following file: > > JBOSS_HOME/standalone/configuration/standalone.xml > > Near the end of the file you'll find the section. Edit the > interfaces named "public" and "unsecure", which contain the following > value > > > > and change it to this: > > > > Restart the JBoss instance and your Zanata server should be accessible > from the outside world. > > We'll make sure that is corrected for the next release. > > Regards, > > Carlos A Munoz > Red Hat > > On Wed, 2013-09-04 at 14:44 +0200, Nghia Duong wrote: > > Hi all, > > > > > > I am trying to deploy the Zanata 3.0.2 standalone server that I > > downloaded as a .zip from the official page. > > > > > > Everything seems to work fine so far, except that Zanata (or the JBoss > > server) listens on 127.0.0.1:8080 by default. Hence it is impossible > > to access the web application from elsewhere than from the host > > computer itself. > > > > > > While greping around, I found that the address was hard-coded in more > > than one configuration files domain.xml, host.xml, host-master.xml, > > host-slave.xml (all in the domain/configuration folder). > > > > > > My question is: is there a clean way (= a configuration option only to > > be modified once) to change the default address on which the server > > listens? > > > > > > I am already hosting a Zanata 3.0.0 development snapshot and it seems > > to "know" the right address to listen on so that the web application > > can be accessed from outside. But since the folder structures has > > obviously changed a lot, I can't find where this option was set in > > Zanata 3.0.0. > > > > > > > > > > Thanks in advance, > > > > > > Nghia > > _______________________________________________ > > zanata-users mailing list > > zanata-users at redhat.com > > https://www.redhat.com/mailman/listinfo/zanata-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nghia.duong at crossknowledge.com Thu Sep 5 15:28:11 2013 From: nghia.duong at crossknowledge.com (Nghia Duong) Date: Thu, 5 Sep 2013 17:28:11 +0200 Subject: [zanata-users] Rest API Documentation down? In-Reply-To: References: Message-ID: And I forgot, here is the stack trace when I try to upload my POT file via the REST API (my requests worked with Zanata 3.0.0) javax.persistence.PersistenceException: org.hibernate.exception.GenericJDBCException: could not execute statement at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1387) at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1310) at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1316) at org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:999) at sun.reflect.GeneratedMethodAccessor930.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.jboss.seam.persistence.EntityManagerInvocationHandler.invoke(EntityManagerInvocationHandler.java:46) at sun.proxy.$Proxy197.flush(Unknown Source) at org.hibernate.search.jpa.impl.FullTextEntityManagerImpl.flush(FullTextEntityManagerImpl.java:157) at sun.reflect.GeneratedMethodAccessor930.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.jboss.seam.persistence.EntityManagerInvocationHandler.invoke(EntityManagerInvocationHandler.java:46) at sun.proxy.$Proxy198.flush(Unknown Source) at org.zanata.rest.service.ResourceUtils.transferFromTextFlows(ResourceUtils.java:201) at org.zanata.rest.service.ResourceUtils.transferFromResource(ResourceUtils.java:235) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.jboss.seam.util.Reflections.invoke(Reflections.java:22) at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:32) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56) at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:77) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107) at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:186) at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:104) at org.zanata.rest.service.ResourceUtils_$$_javassist_seam_62.transferFromResource(ResourceUtils_$$_javassist_seam_62.java) at org.zanata.service.impl.DocumentServiceImpl.saveDocument(DocumentServiceImpl.java:148) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.jboss.seam.util.Reflections.invoke(Reflections.java:22) at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:32) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56) at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:77) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.transaction.TransactionInterceptor$1.work(TransactionInterceptor.java:97) at org.jboss.seam.util.Work.workInTransaction(Work.java:61) at org.jboss.seam.transaction.TransactionInterceptor.aroundInvoke(TransactionInterceptor.java:91) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107) at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:186) at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:104) at org.zanata.service.impl.DocumentServiceImpl_$$_javassist_seam_78.saveDocument(DocumentServiceImpl_$$_javassist_seam_78.java) at org.zanata.rest.service.SourceDocResourceService.putResource(SourceDocResourceService.java:352) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.jboss.seam.util.Reflections.invoke(Reflections.java:22) at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:32) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56) at org.jboss.seam.resteasy.ResteasyContextInjectionInterceptor.aroundInvoke(ResteasyContextInjectionInterceptor.java:59) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:77) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.transaction.TransactionInterceptor$1.work(TransactionInterceptor.java:97) at org.jboss.seam.util.Work.workInTransaction(Work.java:61) at org.jboss.seam.transaction.TransactionInterceptor.aroundInvoke(TransactionInterceptor.java:91) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.security.SecurityInterceptor.aroundInvoke(SecurityInterceptor.java:163) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107) at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:186) at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:104) at org.zanata.rest.service.SourceDocResourceService_$$_javassist_seam_106.putResource(SourceDocResourceService_$$_javassist_seam_106.java) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167) at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:257) at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:222) at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:211) at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126) at org.zanata.rest.ZanataResteasyBootstrap$1.invoke(ZanataResteasyBootstrap.java:74) at org.jboss.seam.resteasy.ResteasyResourceAdapter$1.process(ResteasyResourceAdapter.java:145) at org.jboss.seam.servlet.ContextualHttpServletRequest.run(ContextualHttpServletRequest.java:65) at org.jboss.seam.resteasy.ResteasyResourceAdapter.getResource(ResteasyResourceAdapter.java:120) at org.jboss.seam.servlet.SeamResourceServlet.service(SeamResourceServlet.java:80) at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:163) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) at org.tuckey.web.filters.urlrewrite.RuleChain.handleRewrite(RuleChain.java:176) at org.tuckey.web.filters.urlrewrite.RuleChain.doRules(RuleChain.java:145) at org.tuckey.web.filters.urlrewrite.UrlRewriter.processRequest(UrlRewriter.java:92) at org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:389) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83) at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:60) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:73) at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) at org.zanata.seam.interceptor.MonitoringWrapper.doFilter(MonitoringWrapper.java:70) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) at org.zanata.servlet.GWTCacheControlFilter.doFilter(GWTCacheControlFilter.java:63) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) at org.jboss.security.negotiation.NegotiationAuthenticator$1.invoke(NegotiationAuthenticator.java:326) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:389) at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920) at java.lang.Thread.run(Thread.java:679) Caused by: org.hibernate.exception.GenericJDBCException: could not execute statement at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:54) at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:125) at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:110) at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:136) at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:3219) at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:3117) at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:3446) at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:140) at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:362) at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:354) at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:276) at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:328) at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1233) at org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:996) ... 134 more Caused by: java.sql.SQLException: Thread stack overrun: 9424 bytes used of a 131072 byte stack, and 128000 bytes needed. Use 'mysqld -O thread_stack=#' to specify a bigger stack. at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1073) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3609) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3541) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2002) at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2163) at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2624) at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2127) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2427) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2345) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2330) at sun.reflect.GeneratedMethodAccessor828.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at net.bull.javamelody.JdbcWrapper.doExecute(JdbcWrapper.java:373) at net.bull.javamelody.JdbcWrapper$StatementInvocationHandler.invoke(JdbcWrapper.java:130) at net.bull.javamelody.JdbcWrapper$DelegatingInvocationHandler.invoke(JdbcWrapper.java:259) at sun.proxy.$Proxy200.executeUpdate(Unknown Source) at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493) at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:133) ... 145 more Regards, Nghia 2013/9/5 Nghia Duong > Hi all, > > I just wanted to point out that the REST API Documentation ( > https://zanata.ci.cloudbees.com/job/zanata-site/site/zanata-war/apidocs/index.html) > has been down since quite some time. > > I'm using that API on Zanta 3.0.2 and would like to know whether there has > been any changes to it, especially around regarding timeouts (I'm trying to > upload a POT file a a source document and I always get a 500 internal > error). > > Has the documentation been moved to somewhere else? > > > Thanks, > > Nghia > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sankarshan.mukhopadhyay at gmail.com Fri Sep 6 05:20:59 2013 From: sankarshan.mukhopadhyay at gmail.com (Sankarshan Mukhopadhyay) Date: Fri, 6 Sep 2013 10:50:59 +0530 Subject: [zanata-users] List-forking. A clarification about Zanata admin rights Message-ID: Hi, Isaac pointed out, rightfully so, that hijacking a self-introduction thread was poor form. mentions: "For the coordinator of each language team who has not yet gained the admin privilege of your language team in ZANATA, please contact Issac, me or Red Hat employees of your language team. We will be happy to grant the admin privilege to you. (You must to be current coordinator on the team list.)" So, if I break it down, if I were seeking admin access to Bengali(India), I'd have to write in to either: - Isaac - Noriko - Or, whoever in my language team is also a Red Hat employee The clarification I seek is about this third actor. How is it that a Red Hat employee, who may be a contributor to my language, is by default able to grant me (a non Red Hat employee) admin access? As I mentioned at , "Usually, for other systems that I am familiar with, when a member of the language community desires admin access as a coordinator of the language, they write to the admin of the infrastructure/ticketing system. In this case, it appears to be otherwise. So, I wanted to know if there is a plan to change the system that you have in place with something else." Additionally, could you also clarify if Zanata uses "admin" and, language coordinator as synonyms? Translation Content Management systems prefer the latter than the former. Admin is usually reserved for those who have access to the infrastructure. -- sankarshan mukhopadhyay From sflaniga at redhat.com Fri Sep 6 05:53:27 2013 From: sflaniga at redhat.com (Sean Flanigan) Date: Fri, 06 Sep 2013 15:53:27 +1000 Subject: [zanata-users] Rest API Documentation down? In-Reply-To: References: Message-ID: <52296DD7.3080207@redhat.com> Hi Nghia Are you writing code against the REST API? Which language are you using? If you are, a very old version of the REST docs can be found here: https://zanata.ci.cloudbees.com/view/All/job/zanata-server-site/site/zanata-war/apidocs/index.html but that URL will change if we get the cloudbees build to work again. At present, I'm afraid the only place to get up to date info about the REST API (including async push) is the source code: https://github.com/zanata/zanata-api/tree/master/zanata-common-api/src/main/java/org/zanata But if you are coding against the REST API, do let us know, and we'll try to do something about improving the situation. (If you are writing Java code, you can use the Java classes directly, as we do in the Java clients for Zanata.) On the other hand, if you are trying to use a command-line Zanata client, we have some new documentation under development. It has been moving around, but right now it can be found here: http://zanata.org/new/help/ If you are using the Python client, it doesn't support the async push API, which is needed for larger source documents (eg POT). The Java client does support async push. If you want to use it, see the help URL above. Regards Sean. On 2013-09-06 01:11, Nghia Duong wrote: > Hi all, > > I just wanted to point out that the REST API Documentation > (https://zanata.ci.cloudbees.com/job/zanata-site/site/zanata-war/apidocs/index.html) > has been down since quite some time. > > I'm using that API on Zanta 3.0.2 and would like to know whether there > has been any changes to it, especially around regarding timeouts (I'm > trying to upload a POT file a a source document and I always get a 500 > internal error). > > Has the documentation been moved to somewhere else? > > > Thanks, > > Nghia > > > _______________________________________________ > zanata-users mailing list > zanata-users at redhat.com > https://www.redhat.com/mailman/listinfo/zanata-users > -- 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: 295 bytes Desc: OpenPGP digital signature URL: From sflaniga at redhat.com Fri Sep 6 06:31:57 2013 From: sflaniga at redhat.com (Sean Flanigan) Date: Fri, 06 Sep 2013 16:31:57 +1000 Subject: [zanata-users] List-forking. A clarification about Zanata admin rights In-Reply-To: References: Message-ID: <522976DD.8060601@redhat.com> On 2013-09-06 15:20, Sankarshan Mukhopadhyay wrote: > Hi, > > Isaac pointed out, rightfully so, that hijacking a self-introduction > thread was poor form. > > > mentions: > > "For the coordinator of each language team who has not yet gained the > admin privilege of your language team in ZANATA, please contact Issac, > me or Red Hat employees of your language team. We will be happy to grant > the admin privilege to you. (You must to be current coordinator on the > team list.)" For "admin privilege", read "coordinator privilege". Admin is something else. (See below.) > > So, if I break it down, if I were seeking admin access to > Bengali(India), I'd have to write in to either: > > - Isaac > - Noriko > - Or, whoever in my language team is also a Red Hat employee > > The clarification I seek is about this third actor. How is it that a > Red Hat employee, who may be a contributor to my language, is by > default able to grant me (a non Red Hat employee) admin access? Being a Red Hat employee doesn't grant anyone special privileges in Zanata, but I suppose the first language team member is likely to be a team coordinator and the first language team member is also likely to be from Red Hat. If you want to volunteer for the coordinator role, you can click "Contact Language Team Coordinators" and send a request. If there are any existing coordinators, it will go to them, otherwise this will go to an admin mailing list. A team coordinator, or any admin, can make another team member into a coordinator for that team. (Actually, Noriko, Isaac, mind if we add you to that mailing list?) > As I mentioned at > , > > "Usually, for other systems that I am familiar with, when a member of > the language community > desires admin access as a coordinator of the language, they write to > the admin of the infrastructure/ticketing system. In this case, it > appears to be otherwise. No, same here. > So, I wanted to know if there is a plan to > change the system that you have in place with something else." Not that I know of. > Additionally, could you also clarify if Zanata uses "admin" and, > language coordinator as synonyms? Translation Content Management > systems prefer the latter than the former. Admin is usually reserved > for those who have access to the infrastructure. That's right, admin is a global privilege level, whereas language coordinator is a lower privilege level which applies to a single language. -- 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: 295 bytes Desc: OpenPGP digital signature URL: From damason at redhat.com Fri Sep 6 06:39:18 2013 From: damason at redhat.com (David Mason) Date: Fri, 6 Sep 2013 02:39:18 -0400 (EDT) Subject: [zanata-users] List-forking. A clarification about Zanata admin rights In-Reply-To: References: Message-ID: <1786404814.10185114.1378449558580.JavaMail.root@redhat.com> Hi Sankarshan, See responses inline. ----- Original Message ----- > From: "Sankarshan Mukhopadhyay" > To: zanata-users at redhat.com > Sent: Friday, 6 September, 2013 3:20:59 PM > Subject: [zanata-users] List-forking. A clarification about Zanata admin rights > > Hi, > > Isaac pointed out, rightfully so, that hijacking a self-introduction > thread was poor form. > > > mentions: > > "For the coordinator of each language team who has not yet gained the > admin privilege of your language team in ZANATA, please contact Issac, > me or Red Hat employees of your language team. We will be happy to grant > the admin privilege to you. (You must to be current coordinator on the > team list.)" > > So, if I break it down, if I were seeking admin access to > Bengali(India), I'd have to write in to either: > > - Isaac > - Noriko > - Or, whoever in my language team is also a Red Hat employee The correct procedure at the moment to become a language team coordinator is to go to the page in Zanata for the language and make a request from that page using "Request to Join Team" or "Contact Team Coordinators" - in either of those there is an input field for a message where you can ask to be made a coordinator, and in this specific instance it would be prudent to give a link to the thread linked above and any information that will help to identify who you are. Using this procedure, one of two things will happen. 1. If there are already one or more language coordinators, the message will be sent to them and they can decide how to respond. Any language team that has a coordinator is essentially self-managing and Zanata administrators do not generally interfere with that. 2. If there is not yet a language coordinator, the message will be sent to Zanata administrators, who will usually try to assign a qualified coordinator as soon as possible so that we can let the translation community manage themselves without further interference from us. Obviously this is not ideal. See below. > The clarification I seek is about this third actor. How is it that a > Red Hat employee, who may be a contributor to my language, is by > default able to grant me (a non Red Hat employee) admin access? Not all Red Hat employees have these kind of privileges. For many language teams, the coordinators happen to be Red Hat employees simply because so many of the translators on Zanata work for Red Hat. As for system-wide admins, most of them are members of the development team who program Zanata, who are all employed by Red Hat - as mentioned we ideally want all language team management to be done by the community, but at the moment our way of bootstrapping the community management requires some manual work from us, which is not ideal (partly because it uses some time we could be using for adding features, but mainly because it should not be arbitrarily up to us to decide who can lead a language team). > As I mentioned at > , > > "Usually, for other systems that I am familiar with, when a member of > the language community > desires admin access as a coordinator of the language, they write to > the admin of the infrastructure/ticketing system. In this case, it > appears to be otherwise. So, I wanted to know if there is a plan to > change the system that you have in place with something else." I have some personal goals for the system to completely remove the requirement to contact anyone (even a ticketing system), to remove the requirement to manually assign coordinators, and in fact remove any requirement for having to manually assign any user to any role - instead translators should be able to start translating and gain more privileges as they prove that they are good at it. This will take a while to implement, but the basic idea is that anyone should be able to suggest translations for any language, and from there they can build up a reputation score any language that they are able to translate to a high standard. The system will still require some bootstrapping* but will be a lot better than the current situation, where a translator has to wait for someone before they can enter any translations, and where coordinators feel they have insufficient information to decide whether someone should be allowed to join a language team. * to deal with the issue of who reviews the suggestions by the first translator for a language, before anyone has enough reputation to be a reviewer. I have a few RFEs for the start of these changes (just a start of course): - https://bugzilla.redhat.com/show_bug.cgi?id=919253 - https://bugzilla.redhat.com/show_bug.cgi?id=919258 - https://bugzilla.redhat.com/show_bug.cgi?id=919262 > Additionally, could you also clarify if Zanata uses "admin" and, > language coordinator as synonyms? Translation Content Management > systems prefer the latter than the former. Admin is usually reserved > for those who have access to the infrastructure. In Zanata "admin" and "language coordinator" are completely different concepts: - language coordinator: user who is in charge of a specific language team (a single locale) who can add and remove users from that language team, assign review privileges to team members, and assign other coordinators for their team (there can be any number of coordinators for each team). - admin: a small number of users (mainly the development team) who have access to all the server management features. Admins also handle requests for language teams that have no coordinator (and usually try to assign a coordinator as soon as possible). I hope that adequately answers your questions. I'm happy to clarify or answer any more questions you might have - I think that community governance of the translation process is the most important issue to deal with and get right as we develop Zanata. Cheers, David Mason Software Engineer L10n Engineering Red Hat, Asia-Pacific Pty Ltd Level 1, 193 North Quay Brisbane 4000 From sankarshan.mukhopadhyay at gmail.com Fri Sep 6 06:40:33 2013 From: sankarshan.mukhopadhyay at gmail.com (Sankarshan Mukhopadhyay) Date: Fri, 6 Sep 2013 12:10:33 +0530 Subject: [zanata-users] List-forking. A clarification about Zanata admin rights In-Reply-To: <522976DD.8060601@redhat.com> References: <522976DD.8060601@redhat.com> Message-ID: On Fri, Sep 6, 2013 at 12:01 PM, Sean Flanigan wrote: > Being a Red Hat employee doesn't grant anyone special privileges in > Zanata, but I suppose the first language team member is likely to be a > team coordinator and the first language team member is also likely to be > from Red Hat. Perhaps not entirely accurate. Unless Zanata (in the shape of translate.zanata.org) plans to limit the language/locale support to the 22 or, 24 that Red Hat supports as part of Red Hat products. There is a wide array of locales/languages which may be attracted to use Zanata as their platform. This entire conversation has been intended to point out that the "actors to contact" as listed in Noriko's email could be replaced by a list of team-coordinators or, language administrators who can bless a new contributor with an appropriate role. The paragraph you write below seems to indicate that this workflow exists. So, the "contact individuals" workflow can be considered redundant. You do have the choice of calling me a pedant. However, the more inclusive and less restrictive an infrastructure project (like Zanata) is, the more dead-simple it makes team formation, the faster is the adoption and update. But you already know all of this ... > If you want to volunteer for the coordinator role, you can click > "Contact Language Team Coordinators" and send a request. If there are > any existing coordinators, it will go to them, otherwise this will go to > an admin mailing list. A team coordinator, or any admin, can make > another team member into a coordinator for that team. /s From sankarshan.mukhopadhyay at gmail.com Fri Sep 6 07:04:10 2013 From: sankarshan.mukhopadhyay at gmail.com (Sankarshan Mukhopadhyay) Date: Fri, 6 Sep 2013 12:34:10 +0530 Subject: [zanata-users] Discussing RFEs [was: List-forking. A clarification about Zanata admin rights] Message-ID: I deeply appreciate that you took time to share a set of the RFEs. I went through them and, have a few comments, I'll in-line them against the respective RFEs. On Fri, Sep 6, 2013 at 12:09 PM, David Mason wrote: > I have a few RFEs for the start of these changes (just a start of course): > > - https://bugzilla.redhat.com/show_bug.cgi?id=919253 "User is able to enter not-accepted translations for any language, which would be queued for review by a user with higher permissions for that language." This is an interesting piece. And, often during translation sprints/marathons this piece comes up. New users are unwilling to go through the process of signing up and, want to know why they cannot queue up translations for review and acceptance. There is a particular reason why sign-up and acceptance into a team is often part of a language team's "new contributor orientation". Translations are expensive to maintain (in the same way, code is). And, incorrect or, inaccurate translations take a high toll on language communities who have to review (much in the same was as code review via systems like Gerrit often become a sore point due to the backlog it acquires; since reviewers are a scarce resource). So, "seagull contributions" (ie. fly in, do something, fly away) are often more costly and looked at askance by language communities. The ability to sign-up and participate ensures that the coordinator can track existing contributors, they can assign tasks and, also do capacity planning. As awkward as it sounds, for language communities to be able to deliver a specific degree of coverage, language coordinators are effectively program managers who deal with a lot of moving pieces. Having unknown/untrained contributors put in small segments, even if they are intended to be qualifying tests, is an expensive proposition. > - https://bugzilla.redhat.com/show_bug.cgi?id=919258 "Add a reputation score that is calculated based on total count of approved translations, rejected translations, translations the user has reviewed, and any other relevant measures. The score should reflect both the quality and the volume of translations the user has submitted." I do like this one. This brings in two specific elements - socializing translation contributions and, gamification. I'd really like to see this introduced. > - https://bugzilla.redhat.com/show_bug.cgi?id=919262 "If a user has a high reputation score for a language, they should automatically be assigned save-approved permission for that language." I'd probably hesitate to agree to automatic assignment of permissions. Translation systems are workflows and, like all workflows, there is a specific need to have the ACLs set up. The ACLs are not gates or, high fences - they are somewhat of a milestone which is checked off for someone who has contributed enough. For example, Pootle allows the quantum of contributions to be visible for a contributor. Additionally, since language communities are well-knit and tightly integrated, the reputation-based ACLs are put in place faster than perhaps communities of code. /s -- sankarshan mukhopadhyay From nghia.duong at crossknowledge.com Fri Sep 6 07:24:52 2013 From: nghia.duong at crossknowledge.com (Nghia Duong) Date: Fri, 6 Sep 2013 09:24:52 +0200 Subject: [zanata-users] Rest API Documentation down? In-Reply-To: <52296DD7.3080207@redhat.com> References: <52296DD7.3080207@redhat.com> Message-ID: Thanks for the quick answer Sean, I am coding against Zanata's REST API with PHP (creating cURL requests with the right infos depending on the actions I want to perform). While re-reading the error log I saw a MySQL insufficient thread stack size problem, I will try to increase that and see where it leads me. If other people want to use PHP to interact with the API, here's what I have: https://github.com/adlq/zanata-php-toolkit. It is under-documented and under development but it does the job of uploading POT source documents and translations (which is what I need). Regards, Nghia 2013/9/6 Sean Flanigan > Hi Nghia > > Are you writing code against the REST API? Which language are you using? > > > If you are, a very old version of the REST docs can be found here: > > > https://zanata.ci.cloudbees.com/view/All/job/zanata-server-site/site/zanata-war/apidocs/index.html > > but that URL will change if we get the cloudbees build to work again. > > > At present, I'm afraid the only place to get up to date info about the > REST API (including async push) is the source code: > > > https://github.com/zanata/zanata-api/tree/master/zanata-common-api/src/main/java/org/zanata > > But if you are coding against the REST API, do let us know, and we'll > try to do something about improving the situation. > > > (If you are writing Java code, you can use the Java classes directly, as > we do in the Java clients for Zanata.) > > > > On the other hand, if you are trying to use a command-line Zanata > client, we have some new documentation under development. It has been > moving around, but right now it can be found here: > http://zanata.org/new/help/ > > > If you are using the Python client, it doesn't support the async push > API, which is needed for larger source documents (eg POT). > > The Java client does support async push. If you want to use it, see the > help URL above. > > > Regards > > Sean. > > On 2013-09-06 01:11, Nghia Duong wrote: > > Hi all, > > > > I just wanted to point out that the REST API Documentation > > ( > https://zanata.ci.cloudbees.com/job/zanata-site/site/zanata-war/apidocs/index.html > ) > > has been down since quite some time. > > > > I'm using that API on Zanta 3.0.2 and would like to know whether there > > has been any changes to it, especially around regarding timeouts (I'm > > trying to upload a POT file a a source document and I always get a 500 > > internal error). > > > > Has the documentation been moved to somewhere else? > > > > > > Thanks, > > > > Nghia > > > > > > _______________________________________________ > > zanata-users mailing list > > zanata-users at redhat.com > > https://www.redhat.com/mailman/listinfo/zanata-users > > > > > -- > Sean Flanigan > > Senior Software Engineer > Engineering - Internationalisation > Red Hat > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pefernan at redhat.com Fri Sep 6 08:05:39 2013 From: pefernan at redhat.com (Pere Fernandez Perez) Date: Fri, 6 Sep 2013 04:05:39 -0400 (EDT) Subject: [zanata-users] Question about project translations In-Reply-To: <75856226.15140001.1378454648054.JavaMail.root@redhat.com> Message-ID: <894657070.15143151.1378454739901.JavaMail.root@redhat.com> Hello, I have a project already translated but I added more entries on a Constants.properties file. Should I push the entire project again or there is a way to push only that file? Reggards, Pere From camunoz at redhat.com Fri Sep 6 08:28:34 2013 From: camunoz at redhat.com (Carlos Munoz) Date: Fri, 6 Sep 2013 04:28:34 -0400 (EDT) Subject: [zanata-users] =?utf-8?q?Question_about_project_translations?= In-Reply-To: <894657070.15143151.1378454739901.JavaMail.root@redhat.com> References: <894657070.15143151.1378454739901.JavaMail.root@redhat.com> Message-ID: <4l7c8chqc1apaweiv16egor1.1378456109809@email.android.com> Hi Pere, You can safely push your whole project again. Zanata will recognize your new entries and leave the rest unchanged, provided they in fact haven't changed. If you still prefer to push a single document, you can use the 'includes' parameter to specify the exact document you want to push. Regards, Carlos Sent from Moxier Mail (http://www.moxier.com) ----- Original Message ----- From: Pere Fernandez Perez To: zanata-users at redhat.com Sent: 06/09/2013 6:05 PM Subject: [zanata-users] Question about project translations Hello, I have a project already translated but I added more entries on a Constants.properties file. Should I push the entire project again or there is a way to push only that file? Reggards, Pere _______________________________________________ zanata-users mailing list zanata-users at redhat.com https://www.redhat.com/mailman/listinfo/zanata-users From noriko at redhat.com Fri Sep 6 09:58:59 2013 From: noriko at redhat.com (Noriko Mizumoto) Date: Fri, 06 Sep 2013 19:58:59 +1000 Subject: [zanata-users] List-forking. A clarification about Zanata admin rights In-Reply-To: <522976DD.8060601@redhat.com> References: <522976DD.8060601@redhat.com> Message-ID: <5229A763.80307@redhat.com> (2013?09?06? 16:31), Sean Flanigan wrote: > On 2013-09-06 15:20, Sankarshan Mukhopadhyay wrote: >> Hi, >> >> Isaac pointed out, rightfully so, that hijacking a self-introduction >> thread was poor form. >> >> >> mentions: >> >> "For the coordinator of each language team who has not yet gained the >> admin privilege of your language team in ZANATA, please contact Issac, >> me or Red Hat employees of your language team. We will be happy to grant >> the admin privilege to you. (You must to be current coordinator on the >> team list.)" > For "admin privilege", read "coordinator privilege". Admin is something > else. (See below.) Thank you for clarifying this. Yes, I mean "coordinator privilege". So I corrected my post at trans list. > >> So, if I break it down, if I were seeking admin access to >> Bengali(India), I'd have to write in to either: >> >> - Isaac >> - Noriko >> - Or, whoever in my language team is also a Red Hat employee >> >> The clarification I seek is about this third actor. How is it that a >> Red Hat employee, who may be a contributor to my language, is by >> default able to grant me (a non Red Hat employee) admin access? > Being a Red Hat employee doesn't grant anyone special privileges in > Zanata, but I suppose the first language team member is likely to be a > team coordinator and the first language team member is also likely to be > from Red Hat. Yes, that is the fact. The first language team member is, in most case, Red Hat translator. And they usually have been contributing Fedora localization activity as Fedora translator, thus maintaining closer communication with their Fedora community language teams. Naturally they know who to be granted the coordinator privilege, and who not to e granted. Again, I've posted this at trans list what I was originally aiming at. > > If you want to volunteer for the coordinator role, you can click > "Contact Language Team Coordinators" and send a request. If there are > any existing coordinators, it will go to them, otherwise this will go to > an admin mailing list. A team coordinator, or any admin, can make > another team member into a coordinator for that team. > > (Actually, Noriko, Isaac, mind if we add you to that mailing list?) Sean, thank you so much. Yes, please do so. noriko > > >> As I mentioned at >> , >> >> "Usually, for other systems that I am familiar with, when a member of >> the language community >> desires admin access as a coordinator of the language, they write to >> the admin of the infrastructure/ticketing system. In this case, it >> appears to be otherwise. > No, same here. > >> So, I wanted to know if there is a plan to >> change the system that you have in place with something else." > Not that I know of. > >> Additionally, could you also clarify if Zanata uses "admin" and, >> language coordinator as synonyms? Translation Content Management >> systems prefer the latter than the former. Admin is usually reserved >> for those who have access to the infrastructure. > That's right, admin is a global privilege level, whereas language > coordinator is a lower privilege level which applies to a single language. > > From damason at redhat.com Fri Sep 6 23:51:28 2013 From: damason at redhat.com (David Mason) Date: Fri, 6 Sep 2013 19:51:28 -0400 (EDT) Subject: [zanata-users] Discussing RFEs [was: List-forking. A clarification about Zanata admin rights] In-Reply-To: References: Message-ID: <1255197264.10745954.1378511488584.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Sankarshan Mukhopadhyay" > Cc: zanata-users at redhat.com > Sent: Friday, 6 September, 2013 5:04:10 PM > Subject: Re: [zanata-users] Discussing RFEs [was: List-forking. A clarification about Zanata admin rights] > > I deeply appreciate that you took time to share a set of the RFEs. I > went through them and, have a few comments, I'll in-line them against > the respective RFEs. > > On Fri, Sep 6, 2013 at 12:09 PM, David Mason wrote: > > I have a few RFEs for the start of these changes (just a start of course): > > > > - https://bugzilla.redhat.com/show_bug.cgi?id=919253 > > "User is able to enter not-accepted translations for any language, > which would be queued for review by a user with higher permissions for > that language." > > This is an interesting piece. And, often during translation > sprints/marathons this piece comes up. New users are unwilling to go > through the process of signing up and, want to know why they cannot > queue up translations for review and acceptance. > > There is a particular reason why sign-up and acceptance into a team is > often part of a language team's "new contributor orientation". > Translations are expensive to maintain (in the same way, code is). > And, incorrect or, inaccurate translations take a high toll on > language communities who have to review (much in the same was as code > review via systems like Gerrit often become a sore point due to the > backlog it acquires; since reviewers are a scarce resource). > > So, "seagull contributions" (ie. fly in, do something, fly away) are > often more costly and looked at askance by language communities. The > ability to sign-up and participate ensures that the coordinator can > track existing contributors, they can assign tasks and, also do > capacity planning. As awkward as it sounds, for language communities > to be able to deliver a specific degree of coverage, language > coordinators are effectively program managers who deal with a lot of > moving pieces. Having unknown/untrained contributors put in small > segments, even if they are intended to be qualifying tests, is an > expensive proposition. I agree that a review queue is probably not the best way to handle suggestions - these are evolving ideas, with plenty of room for improvement. The concept I have in mind at the moment is that suggested translations by someone with low reputation would be presented as an option for a more experienced translator to copy as a starting point or to use as-is, something like the way translation memory is presented at the moment. The intention is that the more experienced translator would be able to tell from looking at the suggestions for the first few strings in a document whether the suggestions from a particular user are of high enough quality for them to use, so that the overhead from lower quality suggestions is not high. I think the concept is best communicated as a narrative - a bit long but I think it conveys the spirit of what I'm aiming for better than just listing implementation specifics: Let us assume that 3 new users (let's call them A, B and C) have suggested translations for a language in for some or most of the strings in a document. An experienced translator (I'll call them T) then opens the document for translation. T focuses on the space for the first string and sees 3 suggestions next to the editor (and some TM matches, but I'll ignore those for brevity). The suggestion from B is just some rubbish, not even related to the translation, so T presses an [x] to hide that suggestion forever. The suggestion from A looks ok, but uses some unusual words - T just leaves it. The suggestion from C is quite good, so T clicks a button to copy it to the editor, changes a word, saves it as the translation and moves to the next string. The next string has 2 suggestions. There's more rubbish from B, so T takes a moment to click B's name and and select the option to hide all of B's translations forever. The other suggestion is from A, which is again using some unusual word choices but is a decent grammatical structure, so T clicks to copy it to the editor, changes the words to be the more conventional words, saves it and moves to the next string. The next string has a translation from C that looks exactly correct (and one from A, but T ignores that one since C seems to generally have higher quality), so T copies the string from C and saves it without any changes. This continues through the document. T never sees any more rubbish from B. T uses a few translations from A (with modifications) but decides after a while that it feels slower than just writing them from scratch, so T uses an option to hide all translations from A temporarily (maybe for a few weeks or a month). For most of the strings, T uses translations from C with only small changes. Now, there are some other sides to this story which is quite important. First there is B's story: B is basically just a troll who is wasting people's time. B put rubbish on lots of documents in lots of projects, so a few other translators in addition to T chose to hide all of B's suggestions forever. This automatically reduces B's reputation, and it very quickly drops low enough for all of B's suggestions to be hidden from everyone (maybe B can still see them, but no one else's time is wasted). Next there is C's story: C is an experienced translator who just hasn't used Zanata before so doesn't have any reputation in the system yet. Whenever T used one of C's translations without changing it, C's reputation automatically increased. When a suggestion was used but modified, C has a notification on their dashboard where they can see the difference between what they suggested and what was used (but does not get any reputation if the string was changed). Because T used enough strings without having to change them, C soon has enough reputation to have translator permissions in their language. Finally there is A's story: A is a student translator who has studied for a semester or two and is trying to get some practice and learn. They carefully study all the notifications from when T used their suggestions with different word choices, and gets a better idea of which words are commonly used. A does not get enough reputation to have full translator permission yet, but the automatic feedback from T and other translators lets them improve. After about a month of making suggestions, finally one of A's suggestions is used without any changes, and A gets their first true reputation point towards getting translator permission. With this encouragement, A continues to make suggestions and study hard, and eventually has increasingly many suggestions used without modification, and gets full translation permission. An important point I want to make is that a reputation system needs to be carefully tuned to make it work for the community and have a positive impact. The story above contains some important elements that I would like to be aiming for with a reputation system and other associated changes, and it is these and other important elements that I want to keep in mind when designing and adjusting such a system. I mention adjusting because this is the sort of thing that will be very difficult to get exactly right straight away, but can reach a good balance over time if we look carefully at how the community reacts to it. I have responses to your other comments, but will leave those until Monday since I have a very full weekend. Cheers, David Mason Software Engineer L10n Engineering Red Hat, Asia-Pacific Pty Ltd Level 1, 193 North Quay Brisbane 4000 From irooskov at redhat.com Sun Sep 8 22:36:44 2013 From: irooskov at redhat.com (Isaac Rooskov) Date: Mon, 09 Sep 2013 08:36:44 +1000 Subject: [zanata-users] List-forking. A clarification about Zanata admin rights In-Reply-To: <5229A763.80307@redhat.com> References: <522976DD.8060601@redhat.com> <5229A763.80307@redhat.com> Message-ID: <522CFBFC.7080805@redhat.com> Sounds good to be, thanks Sean :) On 09/06/2013 07:58 PM, Noriko Mizumoto wrote: > (2013? 09?06? 16:31), Sean Flanigan wrote: >> On 2013-09-06 15:20, Sankarshan Mukhopadhyay wrote: >>> Hi, >>> >>> Isaac pointed out, rightfully so, that hijacking a self-introduction >>> thread was poor form. >>> >>> >>> >>> mentions: >>> >>> "For the coordinator of each language team who has not yet gained the >>> admin privilege of your language team in ZANATA, please contact Issac, >>> me or Red Hat employees of your language team. We will be happy to >>> grant >>> the admin privilege to you. (You must to be current coordinator on the >>> team list.)" >> For "admin privilege", read "coordinator privilege". Admin is something >> else. (See below.) > > Thank you for clarifying this. Yes, I mean "coordinator privilege". > So I corrected my post at trans list. > >> >>> So, if I break it down, if I were seeking admin access to >>> Bengali(India), I'd have to write in to either: >>> >>> - Isaac >>> - Noriko >>> - Or, whoever in my language team is also a Red Hat employee >>> >>> The clarification I seek is about this third actor. How is it that a >>> Red Hat employee, who may be a contributor to my language, is by >>> default able to grant me (a non Red Hat employee) admin access? >> Being a Red Hat employee doesn't grant anyone special privileges in >> Zanata, but I suppose the first language team member is likely to be a >> team coordinator and the first language team member is also likely to be >> from Red Hat. > > Yes, that is the fact. > The first language team member is, in most case, Red Hat translator. > And they usually have been contributing Fedora localization activity > as Fedora translator, thus maintaining closer communication with their > Fedora community language teams. Naturally they know who to be granted > the coordinator privilege, and who not to e granted. > Again, I've posted this at trans list what I was originally aiming at. > >> >> If you want to volunteer for the coordinator role, you can click >> "Contact Language Team Coordinators" and send a request. If there are >> any existing coordinators, it will go to them, otherwise this will go to >> an admin mailing list. A team coordinator, or any admin, can make >> another team member into a coordinator for that team. >> >> (Actually, Noriko, Isaac, mind if we add you to that mailing list?) > > Sean, thank you so much. Yes, please do so. > > noriko > > >> >> >>> As I mentioned at >>> , >>> >>> >>> "Usually, for other systems that I am familiar with, when a member of >>> the language community >>> desires admin access as a coordinator of the language, they write to >>> the admin of the infrastructure/ticketing system. In this case, it >>> appears to be otherwise. >> No, same here. >> >>> So, I wanted to know if there is a plan to >>> change the system that you have in place with something else." >> Not that I know of. >> >>> Additionally, could you also clarify if Zanata uses "admin" and, >>> language coordinator as synonyms? Translation Content Management >>> systems prefer the latter than the former. Admin is usually reserved >>> for those who have access to the infrastructure. >> That's right, admin is a global privilege level, whereas language >> coordinator is a lower privilege level which applies to a single >> language. >> >> > -- Isaac Rooskov Supervisor, Localization Services Product Manager, Zanata Red Hat From camunoz at redhat.com Mon Sep 9 00:01:47 2013 From: camunoz at redhat.com (Carlos Munoz) Date: Mon, 09 Sep 2013 10:01:47 +1000 Subject: [zanata-users] Fwd: Re: Question about project translations In-Reply-To: <522D0E0D.3050309@redhat.com> References: <522D0E0D.3050309@redhat.com> Message-ID: <522D0FEB.6060009@redhat.com> Hi Pere, I am forwarding this to the zanata-users list as well. Sean (copied in the email) pointed out to me that using the "includes" option with the client will have the unintended effect of removing all other files when pushing. If you have already pushed with this option, that's not a problem as doing another push with the correct "includes" argument will restore those documents. My initial comment still holds though: pushing the whole set of files will only write whatever is new, leaving all others unchanged. Sorry for the confusion. Regards, Carlos A. Munoz Software Engineering Supervisor Engineering - Internationalization Red Hat On Fri 06 Sep 2013 07:46:17 PM EST, Pere Fernandez Perez wrote: > Hello Carlos, > > I'm having some problems to push just one file, should I do mvn zanata:push -Dincludes= or mvn zanata:push-module -Dincludes=....? > > Reggards, > > Pere > > ----- Mensaje original ----- > De: "Carlos Munoz" > Para: "Pere Fernandez Perez" > CC: zanata-users at redhat.com > Enviados: Viernes, 6 de Septiembre 2013 10:28:34 > Asunto: RE: [zanata-users] Question about project translations > > Hi Pere, > > You can safely push your whole project again. Zanata will recognize your new entries and leave the rest unchanged, provided they in fact haven't changed. > > If you still prefer to push a single document, you can use the 'includes' parameter to specify the exact document you want to push. > > Regards, > > Carlos > > Sent from Moxier Mail > (http://www.moxier.com) > > > ----- Original Message ----- > From: Pere Fernandez Perez > To: zanata-users at redhat.com > Sent: 06/09/2013 6:05 PM > Subject: [zanata-users] Question about project translations > > > Hello, > > I have a project already translated but I added more entries on a Constants.properties file. Should I push the entire project again or there is a way to push only that file? > > Reggards, > > Pere > > _______________________________________________ > zanata-users mailing list > zanata-users at redhat.com > https://www.redhat.com/mailman/listinfo/zanata-users From sankarshan.mukhopadhyay at gmail.com Mon Sep 9 03:51:34 2013 From: sankarshan.mukhopadhyay at gmail.com (Sankarshan Mukhopadhyay) Date: Mon, 9 Sep 2013 09:21:34 +0530 Subject: [zanata-users] Discussing RFEs [was: List-forking. A clarification about Zanata admin rights] In-Reply-To: <1255197264.10745954.1378511488584.JavaMail.root@redhat.com> References: <1255197264.10745954.1378511488584.JavaMail.root@redhat.com> Message-ID: On Sat, Sep 7, 2013 at 5:21 AM, David Mason wrote: > I agree that a review queue is probably not the best way to handle suggestions - these are evolving ideas, with plenty of room for improvement. The concept I have in mind at the moment is that suggested translations by someone with low reputation would be presented as an option for a more experienced translator to copy as a starting point or to use as-is, something like the way translation memory is presented at the moment. The intention is that the more experienced translator would be able to tell from looking at the suggestions for the first few strings in a document whether the suggestions from a particular user are of high enough quality for them to use, so that the overhead from lower quality suggestions is not high. [I loved the narrative and the thought; snipped it here for brevity] I think I can now understand what you are intending to achieve and, it is a somewhat unique spin on the process of contributor participation. A bake-off between contributors leading to a file that may have contributions from all "candidate contributors" hasn't been the typical method of coaching new participants in a community. It could actually work out very nicely by generating a fantastic set of new terms which can then be included in the terminology (used by the translation memory system). For example, I was recently poking around a new entry-level phone from Nokia and, I realized that the terms used for a few UI items (for Bengali) were much more in tune with what is the colloquial form of the language. The next thing was to remember to modify the existing terminology and update it. The process flow that you describe takes this one step further - it would be possible to maintain the attribution (original contributor so to speak) of the term. I'll write a bit more about how file assignment, new contributor on-boarding and, reviews happen. New contributors to a language are few and far between. And, from the ranks of those who sign up only a few remain as long term contributors. So, language coordinators have two tasks - [i] ensure stickiness and, [ii] ensure that whatever has been the random contribution, that has been reviewed and if found acceptable, included. No one wants to throw away whatever little has been received as contributions. (This process may or, may not be followed as is by all languages. What I write is somewhat specific to what we do.) Absolutely newbie contributors are asked to attempt a small subset of strings from a file that is not terribly complex eg. not SELinux or, Virt related. They are asked to go through all the English strings in order to obtain the context of the file/application and, perhaps the use cases (we do ask them to have a machine image for the OS with the application; but often that is not very readily available). Once they do submit their contributions, the reviewer is expected to go through the entire set of strings before reviewing. The reason we ask both parties to read through the file once is to prevent any strange translations ie. words which seem correctly translated but are obviously wrong when placed in context of the entire application or, the specific action in the application. After a few quick cycles of this, the contributor, if (s)he wants to continue, are provided with the rights to commit to the repository themselves and participate in the review sprints. -- sankarshan mukhopadhyay From sankarshan.mukhopadhyay at gmail.com Mon Sep 9 06:11:13 2013 From: sankarshan.mukhopadhyay at gmail.com (Sankarshan Mukhopadhyay) Date: Mon, 9 Sep 2013 11:41:13 +0530 Subject: [zanata-users] List-forking. A clarification about Zanata admin rights In-Reply-To: <5229A763.80307@redhat.com> References: <522976DD.8060601@redhat.com> <5229A763.80307@redhat.com> Message-ID: On Fri, Sep 6, 2013 at 3:28 PM, Noriko Mizumoto wrote: > The first language team member is, in most case, Red Hat translator. > And they usually have been contributing Fedora localization activity as > Fedora translator, thus maintaining closer communication with their Fedora > community language teams. Naturally they know who to be granted the > coordinator privilege, and who not to e granted. I mentioned this in my reply to Sean and, I'll repeat this again. The above assumption holds (and, that too somewhat tenuously) only if you are considering - [i] languages for which Red Hat has a translator on-staff and has published support assurances and, [ii] for those projects which are included in Fedora/RHEL and thus has an on-staff member picking up to the first contributor. There are a larger set of locales and languages which are supported by Zanata out-of-the-box and, for which Zanata could be the platform of choice. Having the Isaac/Noriko/RHT-employee-you-know is then a restrictive practice. You should perhaps take a look at how other large projects handle this and adopt what works. -- sankarshan mukhopadhyay From sflaniga at redhat.com Wed Sep 11 01:44:09 2013 From: sflaniga at redhat.com (Sean Flanigan) Date: Wed, 11 Sep 2013 11:44:09 +1000 Subject: [zanata-users] Rest API Documentation down? In-Reply-To: References: <52296DD7.3080207@redhat.com> Message-ID: <522FCAE9.4020704@redhat.com> Hi Nghia The latest nightly version of the REST API is now documented here: https://zanata.ci.cloudbees.com/job/zanata-api-site/site/zanata-common-api/rest-api-docs/index.html Note that some of the generated links to data type definitions are wrong (404), but if you look up the data type from the home page above, I think it's all there. Also note that new features (eg translation memory import/export) won't be available when running against older servers, and will return 404 responses. Regards Sean. On 2013-09-06 17:24, Nghia Duong wrote: > Thanks for the quick answer Sean, > > I am coding against Zanata's REST API with PHP (creating cURL requests > with the right infos depending on the actions I want to perform). While > re-reading the error log I saw a MySQL insufficient thread stack size > problem, I will try to increase that and see where it leads me. > > If other people want to use PHP to interact with the API, here's what I > have: https://github.com/adlq/zanata-php-toolkit. It is under-documented > and under development but it does the job of uploading POT source > documents and translations (which is what I need). > > Regards, > > Nghia > > > 2013/9/6 Sean Flanigan > > > Hi Nghia > > Are you writing code against the REST API? Which language are you > using? > > > If you are, a very old version of the REST docs can be found here: > > https://zanata.ci.cloudbees.com/view/All/job/zanata-server-site/site/zanata-war/apidocs/index.html > > but that URL will change if we get the cloudbees build to work again. > > > At present, I'm afraid the only place to get up to date info about the > REST API (including async push) is the source code: > > https://github.com/zanata/zanata-api/tree/master/zanata-common-api/src/main/java/org/zanata > > But if you are coding against the REST API, do let us know, and we'll > try to do something about improving the situation. > > > (If you are writing Java code, you can use the Java classes directly, as > we do in the Java clients for Zanata.) > > > > On the other hand, if you are trying to use a command-line Zanata > client, we have some new documentation under development. It has been > moving around, but right now it can be found here: > http://zanata.org/new/help/ > > > If you are using the Python client, it doesn't support the async push > API, which is needed for larger source documents (eg POT). > > The Java client does support async push. If you want to use it, see the > help URL above. > > > Regards > > Sean. > > On 2013-09-06 01:11, Nghia Duong wrote: > > Hi all, > > > > I just wanted to point out that the REST API Documentation > > > (https://zanata.ci.cloudbees.com/job/zanata-site/site/zanata-war/apidocs/index.html) > > has been down since quite some time. > > > > I'm using that API on Zanta 3.0.2 and would like to know whether there > > has been any changes to it, especially around regarding timeouts (I'm > > trying to upload a POT file a a source document and I always get a 500 > > internal error). > > > > Has the documentation been moved to somewhere else? > > > > > > Thanks, > > > > Nghia > > > > > > _______________________________________________ > > zanata-users mailing list > > zanata-users at redhat.com > > https://www.redhat.com/mailman/listinfo/zanata-users > > > > > -- > Sean Flanigan > > Senior Software Engineer > Engineering - Internationalisation > Red Hat > > -- 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: 295 bytes Desc: OpenPGP digital signature URL: From nghia.duong at crossknowledge.com Wed Sep 11 07:14:09 2013 From: nghia.duong at crossknowledge.com (Nghia Duong) Date: Wed, 11 Sep 2013 09:14:09 +0200 Subject: [zanata-users] Rest API Documentation down? In-Reply-To: <522FCAE9.4020704@redhat.com> References: <52296DD7.3080207@redhat.com> <522FCAE9.4020704@redhat.com> Message-ID: That is great news, thank you for the updated documentation, I'll definitely check that out. As for the other issue, increasing the thread stack size solved it for me! Also, do you guys still process the tickets on Bugzilla or should I post the bug over here as well? Regards, Nghia 2013/9/11 Sean Flanigan > Hi Nghia > > The latest nightly version of the REST API is now documented here: > > > https://zanata.ci.cloudbees.com/job/zanata-api-site/site/zanata-common-api/rest-api-docs/index.html > > Note that some of the generated links to data type definitions are wrong > (404), but if you look up the data type from the home page above, I > think it's all there. > > > Also note that new features (eg translation memory import/export) won't > be available when running against older servers, and will return 404 > responses. > > > Regards > > Sean. > > On 2013-09-06 17:24, Nghia Duong wrote: > > Thanks for the quick answer Sean, > > > > I am coding against Zanata's REST API with PHP (creating cURL requests > > with the right infos depending on the actions I want to perform). While > > re-reading the error log I saw a MySQL insufficient thread stack size > > problem, I will try to increase that and see where it leads me. > > > > If other people want to use PHP to interact with the API, here's what I > > have: https://github.com/adlq/zanata-php-toolkit. It is under-documented > > and under development but it does the job of uploading POT source > > documents and translations (which is what I need). > > > > Regards, > > > > Nghia > > > > > > 2013/9/6 Sean Flanigan >> > > > > Hi Nghia > > > > Are you writing code against the REST API? Which language are you > > using? > > > > > > If you are, a very old version of the REST docs can be found here: > > > > > https://zanata.ci.cloudbees.com/view/All/job/zanata-server-site/site/zanata-war/apidocs/index.html > > > > but that URL will change if we get the cloudbees build to work again. > > > > > > At present, I'm afraid the only place to get up to date info about > the > > REST API (including async push) is the source code: > > > > > https://github.com/zanata/zanata-api/tree/master/zanata-common-api/src/main/java/org/zanata > > > > But if you are coding against the REST API, do let us know, and we'll > > try to do something about improving the situation. > > > > > > (If you are writing Java code, you can use the Java classes > directly, as > > we do in the Java clients for Zanata.) > > > > > > > > On the other hand, if you are trying to use a command-line Zanata > > client, we have some new documentation under development. It has > been > > moving around, but right now it can be found here: > > http://zanata.org/new/help/ > > > > > > If you are using the Python client, it doesn't support the async push > > API, which is needed for larger source documents (eg POT). > > > > The Java client does support async push. If you want to use it, see > the > > help URL above. > > > > > > Regards > > > > Sean. > > > > On 2013-09-06 01:11, Nghia Duong wrote: > > > Hi all, > > > > > > I just wanted to point out that the REST API Documentation > > > > > ( > https://zanata.ci.cloudbees.com/job/zanata-site/site/zanata-war/apidocs/index.html > ) > > > has been down since quite some time. > > > > > > I'm using that API on Zanta 3.0.2 and would like to know whether > there > > > has been any changes to it, especially around regarding timeouts > (I'm > > > trying to upload a POT file a a source document and I always get a > 500 > > > internal error). > > > > > > Has the documentation been moved to somewhere else? > > > > > > > > > Thanks, > > > > > > Nghia > > > > > > > > > _______________________________________________ > > > zanata-users mailing list > > > zanata-users at redhat.com > > > https://www.redhat.com/mailman/listinfo/zanata-users > > > > > > > > > -- > > Sean Flanigan > > > > Senior Software Engineer > > Engineering - Internationalisation > > Red Hat > > > > > > > -- > Sean Flanigan > > Senior Software Engineer > Engineering - Internationalisation > Red Hat > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sflaniga at redhat.com Thu Sep 12 03:59:47 2013 From: sflaniga at redhat.com (Sean Flanigan) Date: Thu, 12 Sep 2013 13:59:47 +1000 Subject: [zanata-users] Rest API Documentation down? In-Reply-To: References: <52296DD7.3080207@redhat.com> <522FCAE9.4020704@redhat.com> Message-ID: <52313C33.5090203@redhat.com> Bugzilla is the best option for tracking these things, but you're welcome to discuss bugzillas here too when it makes sense. On 2013-09-11 17:14, Nghia Duong wrote: > That is great news, thank you for the updated documentation, I'll > definitely check that out. > > As for the other issue, increasing the thread stack size solved it for me! > > Also, do you guys still process the tickets on Bugzilla or should I post > the bug over here as well? > > Regards, > > Nghia > > > 2013/9/11 Sean Flanigan > > > Hi Nghia > > The latest nightly version of the REST API is now documented here: > > https://zanata.ci.cloudbees.com/job/zanata-api-site/site/zanata-common-api/rest-api-docs/index.html > > Note that some of the generated links to data type definitions are wrong > (404), but if you look up the data type from the home page above, I > think it's all there. > > > Also note that new features (eg translation memory import/export) won't > be available when running against older servers, and will return 404 > responses. > > > Regards > > Sean. > > On 2013-09-06 17:24, Nghia Duong wrote: > > Thanks for the quick answer Sean, > > > > I am coding against Zanata's REST API with PHP (creating cURL requests > > with the right infos depending on the actions I want to perform). > While > > re-reading the error log I saw a MySQL insufficient thread stack size > > problem, I will try to increase that and see where it leads me. > > > > If other people want to use PHP to interact with the API, here's > what I > > have: https://github.com/adlq/zanata-php-toolkit. It is > under-documented > > and under development but it does the job of uploading POT source > > documents and translations (which is what I need). > > > > Regards, > > > > Nghia > > > > > > 2013/9/6 Sean Flanigan >> > > > > Hi Nghia > > > > Are you writing code against the REST API? Which language are you > > using? > > > > > > If you are, a very old version of the REST docs can be found here: > > > > > https://zanata.ci.cloudbees.com/view/All/job/zanata-server-site/site/zanata-war/apidocs/index.html > > > > but that URL will change if we get the cloudbees build to work > again. > > > > > > At present, I'm afraid the only place to get up to date info > about the > > REST API (including async push) is the source code: > > > > > https://github.com/zanata/zanata-api/tree/master/zanata-common-api/src/main/java/org/zanata > > > > But if you are coding against the REST API, do let us know, > and we'll > > try to do something about improving the situation. > > > > > > (If you are writing Java code, you can use the Java classes > directly, as > > we do in the Java clients for Zanata.) > > > > > > > > On the other hand, if you are trying to use a command-line Zanata > > client, we have some new documentation under development. It > has been > > moving around, but right now it can be found here: > > http://zanata.org/new/help/ > > > > > > If you are using the Python client, it doesn't support the > async push > > API, which is needed for larger source documents (eg POT). > > > > The Java client does support async push. If you want to use > it, see the > > help URL above. > > > > > > Regards > > > > Sean. > > > > On 2013-09-06 01:11, Nghia Duong wrote: > > > Hi all, > > > > > > I just wanted to point out that the REST API Documentation > > > > > > (https://zanata.ci.cloudbees.com/job/zanata-site/site/zanata-war/apidocs/index.html) > > > has been down since quite some time. > > > > > > I'm using that API on Zanta 3.0.2 and would like to know > whether there > > > has been any changes to it, especially around regarding > timeouts (I'm > > > trying to upload a POT file a a source document and I always > get a 500 > > > internal error). > > > > > > Has the documentation been moved to somewhere else? > > > > > > > > > Thanks, > > > > > > Nghia > > > > > > > > > _______________________________________________ > > > zanata-users mailing list > > > zanata-users at redhat.com > > > > > https://www.redhat.com/mailman/listinfo/zanata-users > > > > > > > > > -- > > Sean Flanigan > > > > Senior Software Engineer > > Engineering - Internationalisation > > Red Hat > > > > > > > -- > Sean Flanigan > > Senior Software Engineer > Engineering - Internationalisation > Red Hat > > -- 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: 295 bytes Desc: OpenPGP digital signature URL: From nghia.duong at crossknowledge.com Thu Sep 12 15:13:49 2013 From: nghia.duong at crossknowledge.com (Nghia Duong) Date: Thu, 12 Sep 2013 17:13:49 +0200 Subject: [zanata-users] Bulk-approval of translations? Message-ID: Hi all, I would like to know whether there is a way for reviewers to approve all translations of a given document on Zanata? I have a set of approved translations (from PO files) that I have uploaded (via the REST API) to Zanata. But now they are only saved as translated and not approved, is there any way to approve all of the translations without going through each and everyone of them (I have a lot)? Regards, Nghia -------------- next part -------------- An HTML attachment was scrubbed... URL: From pahuang at redhat.com Thu Sep 12 22:25:36 2013 From: pahuang at redhat.com (Patrick Huang) Date: Thu, 12 Sep 2013 18:25:36 -0400 (EDT) Subject: [zanata-users] Bulk-approval of translations? In-Reply-To: References: Message-ID: <2120055505.14064477.1379024736434.JavaMail.root@redhat.com> Hi Nghia, It's in our product backlog but not yet prioritized into any release yet. We are working on documentations in current release but just so you know, approved state is only required when your project version requires translation review. If your project does not require translation review, Translated state is the synonym of Approved in turns of PO format. To give a concrete example, let's say if you have a PO file with message translation "Approved"(non fuzzy or untranslated), when you push or upload it to the server, it will become Translated. On the other hand, on the server if a message is "Translated", when you pull or download it, the string is represented as "Approved" in PO. Let me know if this helps. Patrick Huang Senior Software Engineer Engineering - Internationalisation Red Hat ----- Original Message ----- > From: "Nghia Duong" > To: zanata-users at redhat.com > Sent: Friday, September 13, 2013 1:13:49 AM > Subject: [zanata-users] Bulk-approval of translations? > Hi all, > I would like to know whether there is a way for reviewers to approve all > translations of a given document on Zanata? > I have a set of approved translations (from PO files) that I have uploaded > (via the REST API) to Zanata. But now they are only saved as translated and > not approved, is there any way to approve all of the translations without > going through each and everyone of them (I have a lot)? > Regards, > Nghia > _______________________________________________ > zanata-users mailing list > zanata-users at redhat.com > https://www.redhat.com/mailman/listinfo/zanata-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From damason at redhat.com Thu Sep 12 23:06:54 2013 From: damason at redhat.com (David Mason) Date: Thu, 12 Sep 2013 19:06:54 -0400 (EDT) Subject: [zanata-users] Bulk-approval of translations? In-Reply-To: <2120055505.14064477.1379024736434.JavaMail.root@redhat.com> References: <2120055505.14064477.1379024736434.JavaMail.root@redhat.com> Message-ID: <2083611951.13016647.1379027214045.JavaMail.root@redhat.com> Hi Nghia, ----- Original Message ----- > From: "Patrick Huang" ... > We are working on documentations in current release but just so you know, > approved state is only required when your project version requires > translation review. The documentation mentioned by Patrick can be previewed at http://zanata.org/new/help/review/review-workflow/ Let me know if you feel there is anything missing or that could be presented better and I can adjust it. Cheers, David Mason Software Engineer L10n Engineering Red Hat, Asia-Pacific Pty Ltd Level 1, 193 North Quay Brisbane 4000 > > > From: "Nghia Duong" > To: zanata-users at redhat.com > Sent: Friday, September 13, 2013 1:13:49 AM > Subject: [zanata-users] Bulk-approval of translations? > > Hi all, > > I would like to know whether there is a way for reviewers to approve all > translations of a given document on Zanata? > > I have a set of approved translations (from PO files) that I have uploaded > (via the REST API) to Zanata. But now they are only saved as translated and > not approved, is there any way to approve all of the translations without > going through each and everyone of them (I have a lot)? > > Regards, > > Nghia From nghia.duong at crossknowledge.com Fri Sep 13 07:06:22 2013 From: nghia.duong at crossknowledge.com (Nghia Duong) Date: Fri, 13 Sep 2013 09:06:22 +0200 Subject: [zanata-users] Bulk-approval of translations? In-Reply-To: <2083611951.13016647.1379027214045.JavaMail.root@redhat.com> References: <2120055505.14064477.1379024736434.JavaMail.root@redhat.com> <2083611951.13016647.1379027214045.JavaMail.root@redhat.com> Message-ID: Hi David and Patrick, Thank you both for the quick answers. @Patrick: It helps to know that this is in your backlog. I am also aware that reviews can be made optional but I am currently trying to sketch out some localization workflows and translation reviews appear essential to me, at least for the QA phase. Would you have any timeline info on when that functionality will be implemented? If I remember correctly, the TranslatedDocResource endpoint of the REST API supports an "ext"parameter when pushing translations, is there anyway I can "force" the approved status there instead? (I can't seem to find the documentation about the content of "ext") @David: Thank you for the documentation, it is very clear to me, but as I said above, I think reviews is necessary for our project. Keep up the good work though! Regards, Nghia 2013/9/13 David Mason > Hi Nghia, > > ----- Original Message ----- > > From: "Patrick Huang" > ... > > We are working on documentations in current release but just so you know, > > approved state is only required when your project version requires > > translation review. > > The documentation mentioned by Patrick can be previewed at > http://zanata.org/new/help/review/review-workflow/ > > Let me know if you feel there is anything missing or that could be > presented better and I can adjust it. > > > Cheers, > > David Mason > Software Engineer > L10n Engineering > > Red Hat, Asia-Pacific Pty Ltd > Level 1, 193 North Quay > Brisbane 4000 > > > > > > > > > From: "Nghia Duong" > > To: zanata-users at redhat.com > > Sent: Friday, September 13, 2013 1:13:49 AM > > Subject: [zanata-users] Bulk-approval of translations? > > > > Hi all, > > > > I would like to know whether there is a way for reviewers to approve all > > translations of a given document on Zanata? > > > > I have a set of approved translations (from PO files) that I have > uploaded > > (via the REST API) to Zanata. But now they are only saved as translated > and > > not approved, is there any way to approve all of the translations without > > going through each and everyone of them (I have a lot)? > > > > Regards, > > > > Nghia > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pahuang at redhat.com Sun Sep 15 22:33:23 2013 From: pahuang at redhat.com (Patrick Huang) Date: Sun, 15 Sep 2013 18:33:23 -0400 (EDT) Subject: [zanata-users] Bulk-approval of translations? In-Reply-To: References: <2120055505.14064477.1379024736434.JavaMail.root@redhat.com> <2083611951.13016647.1379027214045.JavaMail.root@redhat.com> Message-ID: <308342145.15011304.1379284403238.JavaMail.root@redhat.com> Hi Nghia, Priority of RFE (Request for enhancement) is discussed and set by Isaac our product owner before each release. We will finish off Zanata 3.1 release in October and start planning next version. Let's see if it will be scheduled for the next one. As for the ext parameter, it stands for extension. Right now we only support two extensions: "gettext"(deal with PO header etc) and "comment"(comment in PO file). Forcing pulling only Approved translation can be a new RFE. If you want you can fire a bug at https://bugzilla.redhat.com/enter_bug.cgi?format=guided&product=Zanata (You can also access this link from you Zanata instance via footer link Support->Report problem and put "RFE" in front of your bug summary). We will then pick it up from there and prioritize it accordingly. Regards, Patrick Huang Senior Software Engineer Engineering - Internationalisation Red Hat ----- Original Message ----- > From: "Nghia Duong" > To: "David Mason" > Cc: "Patrick Huang" , zanata-users at redhat.com > Sent: Friday, September 13, 2013 5:06:22 PM > Subject: Re: [zanata-users] Bulk-approval of translations? > Hi David and Patrick, > Thank you both for the quick answers. > @Patrick: It helps to know that this is in your backlog. I am also aware that > reviews can be made optional but I am currently trying to sketch out some > localization workflows and translation reviews appear essential to me, at > least for the QA phase. Would you have any timeline info on when that > functionality will be implemented? > If I remember correctly, the TranslatedDocResource endpoint of the REST API > supports an "ext" parameter when pushing translations, is there anyway I can > "force" the approved status there instead? (I can't seem to find the > documentation about the content of "ext") > @David: Thank you for the documentation, it is very clear to me, but as I > said above, I think reviews is necessary for our project. Keep up the good > work though! > Regards, > Nghia > 2013/9/13 David Mason < damason at redhat.com > > > Hi Nghia, > > > ----- Original Message ----- > > > > From: "Patrick Huang" < pahuang at redhat.com > > > > ... > > > > We are working on documentations in current release but just so you know, > > > > approved state is only required when your project version requires > > > > translation review. > > > The documentation mentioned by Patrick can be previewed at > > http://zanata.org/new/help/review/review-workflow/ > > > Let me know if you feel there is anything missing or that could be > > presented > > better and I can adjust it. > > > Cheers, > > > David Mason > > > Software Engineer > > > L10n Engineering > > > Red Hat, Asia-Pacific Pty Ltd > > > Level 1, 193 North Quay > > > Brisbane 4000 > > > > > > > > > > > > From: "Nghia Duong" < nghia.duong at crossknowledge.com > > > > > To: zanata-users at redhat.com > > > > Sent: Friday, September 13, 2013 1:13:49 AM > > > > Subject: [zanata-users] Bulk-approval of translations? > > > > > > > > Hi all, > > > > > > > > I would like to know whether there is a way for reviewers to approve all > > > > translations of a given document on Zanata? > > > > > > > > I have a set of approved translations (from PO files) that I have > > > uploaded > > > > (via the REST API) to Zanata. But now they are only saved as translated > > > and > > > > not approved, is there any way to approve all of the translations without > > > > going through each and everyone of them (I have a lot)? > > > > > > > > Regards, > > > > > > > > Nghia > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sflaniga at redhat.com Tue Sep 17 03:24:08 2013 From: sflaniga at redhat.com (Sean Flanigan) Date: Tue, 17 Sep 2013 13:24:08 +1000 Subject: [zanata-users] Bulk-approval of translations? In-Reply-To: <308342145.15011304.1379284403238.JavaMail.root@redhat.com> References: <2120055505.14064477.1379024736434.JavaMail.root@redhat.com> <2083611951.13016647.1379027214045.JavaMail.root@redhat.com> <308342145.15011304.1379284403238.JavaMail.root@redhat.com> Message-ID: <5237CB58.6000003@redhat.com> From the project maintainer's point of view, I think it could be argued that "requires-approval" projects should only include approved translations when pulling (unless otherwise specified). Otherwise unreviewed translations could be accidentally included in a software/documentation release. So this is a quality issue. Then if someone wants to fetch the translated (non-approved) translations to do some offline translation, that could enabled by a client option. And then you have the problem of preview builds, where someone (maintainer or a translator) pulls down all the translations to generate some sort of preview (eg a Publican build, or a software build), perhaps even as part of the review process. For preview builds, you may want the unapproved translations. The problem is that all three use cases are using the same command, and the most sensible default is different for each use case. Whatever the default should be, we definitely need the ability for the client to choose. On 2013-09-16 08:33, Patrick Huang wrote: > Hi Nghia, > > Priority of RFE (Request for enhancement) is discussed and set by Isaac > our product owner before each release. We will finish off Zanata 3.1 > release in October and start planning next version. Let's see if it will > be scheduled for the next one. > As for the ext parameter, it stands for extension. Right now we only > support two extensions: "gettext"(deal with PO header etc) and > "comment"(comment in PO file). Forcing pulling only Approved > translation can be a new RFE. If you want you can fire a bug at > https://bugzilla.redhat.com/enter_bug.cgi?format=guided&product=Zanata > (You can also access this link from you Zanata instance via footer link > Support->Report problem and put "RFE" in front of your bug summary). We > will then pick it up from there and prioritize it accordingly. > > Regards, > > Patrick Huang > Senior Software Engineer > Engineering - Internationalisation > Red Hat > > ------------------------------------------------------------------------ > > *From: *"Nghia Duong" > *To: *"David Mason" > *Cc: *"Patrick Huang" , zanata-users at redhat.com > *Sent: *Friday, September 13, 2013 5:06:22 PM > *Subject: *Re: [zanata-users] Bulk-approval of translations? > > Hi David and Patrick, > > Thank you both for the quick answers. > > @Patrick: It helps to know that this is in your backlog. I am also > aware that reviews can be made optional but I am currently trying to > sketch out some localization workflows and translation reviews > appear essential to me, at least for the QA phase. Would you have > any timeline info on when that functionality will be implemented? > If I remember correctly, the TranslatedDocResource endpoint of the > REST API supports an "ext" > > parameter when pushing translations, is there anyway I can "force" > the approved status there instead? (I can't seem to find the > documentation about the content of "ext") > > @David: Thank you for the documentation, it is very clear to me, but > as I said above, I think reviews is necessary for our project. Keep > up the good work though! > > > Regards, > > Nghia > > > 2013/9/13 David Mason > > > Hi Nghia, > > ----- Original Message ----- > > From: "Patrick Huang" > > ... > > We are working on documentations in current release but just > so you know, > > approved state is only required when your project version requires > > translation review. > > The documentation mentioned by Patrick can be previewed at > http://zanata.org/new/help/review/review-workflow/ > > Let me know if you feel there is anything missing or that could > be presented better and I can adjust it. > > > Cheers, > > David Mason > Software Engineer > L10n Engineering > > Red Hat, Asia-Pacific Pty Ltd > Level 1, 193 North Quay > Brisbane 4000 > > > > > > > > > From: "Nghia Duong" > > > To: zanata-users at redhat.com > > Sent: Friday, September 13, 2013 1:13:49 AM > > Subject: [zanata-users] Bulk-approval of translations? > > > > Hi all, > > > > I would like to know whether there is a way for reviewers to > approve all > > translations of a given document on Zanata? > > > > I have a set of approved translations (from PO files) that I > have uploaded > > (via the REST API) to Zanata. But now they are only saved as > translated and > > not approved, is there any way to approve all of the > translations without > > going through each and everyone of them (I have a lot)? > > > > Regards, > > > > Nghia > > > > > > _______________________________________________ > zanata-users mailing list > zanata-users at redhat.com > https://www.redhat.com/mailman/listinfo/zanata-users > -- 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: 295 bytes Desc: OpenPGP digital signature URL: From irooskov at redhat.com Tue Sep 24 00:55:55 2013 From: irooskov at redhat.com (Isaac Rooskov) Date: Tue, 24 Sep 2013 10:55:55 +1000 Subject: [zanata-users] Bulk-approval of translations? In-Reply-To: <5237CB58.6000003@redhat.com> References: <2120055505.14064477.1379024736434.JavaMail.root@redhat.com> <2083611951.13016647.1379027214045.JavaMail.root@redhat.com> <308342145.15011304.1379284403238.JavaMail.root@redhat.com> <5237CB58.6000003@redhat.com> Message-ID: <5240E31B.3090706@redhat.com> I agree with Sean on the topic of defaults for this, and that of course we will allow people to alter this as is best for their project. Thanks, Isaac On 09/17/2013 01:24 PM, Sean Flanigan wrote: > From the project maintainer's point of view, I think it could be argued > that "requires-approval" projects should only include approved > translations when pulling (unless otherwise specified). Otherwise > unreviewed translations could be accidentally included in a > software/documentation release. So this is a quality issue. > > Then if someone wants to fetch the translated (non-approved) > translations to do some offline translation, that could enabled by a > client option. > > And then you have the problem of preview builds, where someone > (maintainer or a translator) pulls down all the translations to generate > some sort of preview (eg a Publican build, or a software build), perhaps > even as part of the review process. For preview builds, you may want > the unapproved translations. > > The problem is that all three use cases are using the same command, and > the most sensible default is different for each use case. > > Whatever the default should be, we definitely need the ability for the > client to choose. > > > On 2013-09-16 08:33, Patrick Huang wrote: >> Hi Nghia, >> >> Priority of RFE (Request for enhancement) is discussed and set by Isaac >> our product owner before each release. We will finish off Zanata 3.1 >> release in October and start planning next version. Let's see if it will >> be scheduled for the next one. >> As for the ext parameter, it stands for extension. Right now we only >> support two extensions: "gettext"(deal with PO header etc) and >> "comment"(comment in PO file). Forcing pulling only Approved >> translation can be a new RFE. If you want you can fire a bug at >> https://bugzilla.redhat.com/enter_bug.cgi?format=guided&product=Zanata >> (You can also access this link from you Zanata instance via footer link >> Support->Report problem and put "RFE" in front of your bug summary). We >> will then pick it up from there and prioritize it accordingly. >> >> Regards, >> >> Patrick Huang >> Senior Software Engineer >> Engineering - Internationalisation >> Red Hat >> >> ------------------------------------------------------------------------ >> >> *From: *"Nghia Duong" >> *To: *"David Mason" >> *Cc: *"Patrick Huang" , zanata-users at redhat.com >> *Sent: *Friday, September 13, 2013 5:06:22 PM >> *Subject: *Re: [zanata-users] Bulk-approval of translations? >> >> Hi David and Patrick, >> >> Thank you both for the quick answers. >> >> @Patrick: It helps to know that this is in your backlog. I am also >> aware that reviews can be made optional but I am currently trying to >> sketch out some localization workflows and translation reviews >> appear essential to me, at least for the QA phase. Would you have >> any timeline info on when that functionality will be implemented? >> If I remember correctly, the TranslatedDocResource endpoint of the >> REST API supports an "ext" >> >> parameter when pushing translations, is there anyway I can "force" >> the approved status there instead? (I can't seem to find the >> documentation about the content of "ext") >> >> @David: Thank you for the documentation, it is very clear to me, but >> as I said above, I think reviews is necessary for our project. Keep >> up the good work though! >> >> >> Regards, >> >> Nghia >> >> >> 2013/9/13 David Mason > >> >> Hi Nghia, >> >> ----- Original Message ----- >> > From: "Patrick Huang" > > >> ... >> > We are working on documentations in current release but just >> so you know, >> > approved state is only required when your project version requires >> > translation review. >> >> The documentation mentioned by Patrick can be previewed at >> http://zanata.org/new/help/review/review-workflow/ >> >> Let me know if you feel there is anything missing or that could >> be presented better and I can adjust it. >> >> >> Cheers, >> >> David Mason >> Software Engineer >> L10n Engineering >> >> Red Hat, Asia-Pacific Pty Ltd >> Level 1, 193 North Quay >> Brisbane 4000 >> >> >> >> > >> > >> > From: "Nghia Duong" > > >> > To: zanata-users at redhat.com >> > Sent: Friday, September 13, 2013 1:13:49 AM >> > Subject: [zanata-users] Bulk-approval of translations? >> > >> > Hi all, >> > >> > I would like to know whether there is a way for reviewers to >> approve all >> > translations of a given document on Zanata? >> > >> > I have a set of approved translations (from PO files) that I >> have uploaded >> > (via the REST API) to Zanata. But now they are only saved as >> translated and >> > not approved, is there any way to approve all of the >> translations without >> > going through each and everyone of them (I have a lot)? >> > >> > Regards, >> > >> > Nghia >> >> >> >> >> >> _______________________________________________ >> zanata-users mailing list >> zanata-users at redhat.com >> https://www.redhat.com/mailman/listinfo/zanata-users >> > -- Isaac Rooskov Supervisor, Localization Services Product Manager, Zanata Red Hat From nghia.duong at crossknowledge.com Tue Sep 24 07:14:29 2013 From: nghia.duong at crossknowledge.com (Nghia Duong) Date: Tue, 24 Sep 2013 09:14:29 +0200 Subject: [zanata-users] Bulk-approval of translations? In-Reply-To: <5240E31B.3090706@redhat.com> References: <2120055505.14064477.1379024736434.JavaMail.root@redhat.com> <2083611951.13016647.1379027214045.JavaMail.root@redhat.com> <308342145.15011304.1379284403238.JavaMail.root@redhat.com> <5237CB58.6000003@redhat.com> <5240E31B.3090706@redhat.com> Message-ID: Thank you for your inputs, as of right now, I think I will simply update the specified HTextFlowTargets' state to 3 in the database (I've done this on my test database and apparently it hasn't broken anything yet). Regards, Nghia 2013/9/24 Isaac Rooskov > I agree with Sean on the topic of defaults for this, and that of course we > will allow people to alter this as is best for their project. > > Thanks, > > Isaac > > > On 09/17/2013 01:24 PM, Sean Flanigan wrote: > >> From the project maintainer's point of view, I think it could be argued >> that "requires-approval" projects should only include approved >> translations when pulling (unless otherwise specified). Otherwise >> unreviewed translations could be accidentally included in a >> software/documentation release. So this is a quality issue. >> >> Then if someone wants to fetch the translated (non-approved) >> translations to do some offline translation, that could enabled by a >> client option. >> >> And then you have the problem of preview builds, where someone >> (maintainer or a translator) pulls down all the translations to generate >> some sort of preview (eg a Publican build, or a software build), perhaps >> even as part of the review process. For preview builds, you may want >> the unapproved translations. >> >> The problem is that all three use cases are using the same command, and >> the most sensible default is different for each use case. >> >> Whatever the default should be, we definitely need the ability for the >> client to choose. >> >> >> On 2013-09-16 08:33, Patrick Huang wrote: >> >>> Hi Nghia, >>> >>> Priority of RFE (Request for enhancement) is discussed and set by Isaac >>> our product owner before each release. We will finish off Zanata 3.1 >>> release in October and start planning next version. Let's see if it will >>> be scheduled for the next one. >>> As for the ext parameter, it stands for extension. Right now we only >>> support two extensions: "gettext"(deal with PO header etc) and >>> "comment"(comment in PO file). Forcing pulling only Approved >>> translation can be a new RFE. If you want you can fire a bug at >>> https://bugzilla.redhat.com/**enter_bug.cgi?format=guided&** >>> product=Zanata >>> (You can also access this link from you Zanata instance via footer link >>> Support->Report problem and put "RFE" in front of your bug summary). We >>> will then pick it up from there and prioritize it accordingly. >>> >>> Regards, >>> >>> Patrick Huang >>> Senior Software Engineer >>> Engineering - Internationalisation >>> Red Hat >>> >>> ------------------------------**------------------------------** >>> ------------ >>> >>> *From: *"Nghia Duong" >>> > >>> *To: *"David Mason" >>> *Cc: *"Patrick Huang" , zanata-users at redhat.com >>> *Sent: *Friday, September 13, 2013 5:06:22 PM >>> *Subject: *Re: [zanata-users] Bulk-approval of translations? >>> >>> Hi David and Patrick, >>> >>> Thank you both for the quick answers. >>> >>> @Patrick: It helps to know that this is in your backlog. I am also >>> aware that reviews can be made optional but I am currently trying to >>> sketch out some localization workflows and translation reviews >>> appear essential to me, at least for the QA phase. Would you have >>> any timeline info on when that functionality will be implemented? >>> If I remember correctly, the TranslatedDocResource endpoint of the >>> REST API supports an "ext" >>> >> zanata-common-api/rest-api-**docs/resource_** >>> TranslatedDocResource.html#PUT >>> **> >>> parameter when pushing translations, is there anyway I can "force" >>> the approved status there instead? (I can't seem to find the >>> documentation about the content of "ext") >>> >>> @David: Thank you for the documentation, it is very clear to me, but >>> as I said above, I think reviews is necessary for our project. Keep >>> up the good work though! >>> >>> >>> Regards, >>> >>> Nghia >>> >>> >>> 2013/9/13 David Mason >> damason at redhat.com>> >>> >>> Hi Nghia, >>> >>> ----- Original Message ----- >>> > From: "Patrick Huang" >> > >>> ... >>> > We are working on documentations in current release but just >>> so you know, >>> > approved state is only required when your project version >>> requires >>> > translation review. >>> >>> The documentation mentioned by Patrick can be previewed at >>> http://zanata.org/new/help/**review/review-workflow/ >>> >>> Let me know if you feel there is anything missing or that could >>> be presented better and I can adjust it. >>> >>> >>> Cheers, >>> >>> David Mason >>> Software Engineer >>> L10n Engineering >>> >>> Red Hat, Asia-Pacific Pty Ltd >>> Level 1, 193 North Quay >>> Brisbane 4000 >>> >>> >>> >>> > >>> > >>> > From: "Nghia Duong" >>> >>> >> >>> > To: zanata-users at redhat.com >>> > >>> > Sent: Friday, September 13, 2013 1:13:49 AM >>> > Subject: [zanata-users] Bulk-approval of translations? >>> > >>> > Hi all, >>> > >>> > I would like to know whether there is a way for reviewers to >>> approve all >>> > translations of a given document on Zanata? >>> > >>> > I have a set of approved translations (from PO files) that I >>> have uploaded >>> > (via the REST API) to Zanata. But now they are only saved as >>> translated and >>> > not approved, is there any way to approve all of the >>> translations without >>> > going through each and everyone of them (I have a lot)? >>> > >>> > Regards, >>> > >>> > Nghia >>> >>> >>> >>> >>> >>> ______________________________**_________________ >>> zanata-users mailing list >>> zanata-users at redhat.com >>> https://www.redhat.com/**mailman/listinfo/zanata-users >>> >>> >> > > -- > Isaac Rooskov > Supervisor, Localization Services > Product Manager, Zanata > Red Hat > > -------------- next part -------------- An HTML attachment was scrubbed... URL: