From kde-i18n-doc Sun Mar 31 16:26:17 2019 From: Shinjo Park Date: Sun, 31 Mar 2019 16:26:17 +0000 To: kde-i18n-doc Subject: Re: Use Pontoon for l10n Message-Id: <2076176.Ytuo1Xs9It () ainazi> X-MARC-Message: https://marc.info/?l=kde-i18n-doc&m=155404959629711 2019=EB=85=84 3=EC=9B=94 31=EC=9D=BC =EC=9D=BC=EC=9A=94=EC=9D=BC =EC=98=A4= =EC=A0=84 5=EC=8B=9C 9=EB=B6=84 2=EC=B4=88 CEST=EC=97=90 Subin =EB=8B=98=EC= =9D=B4 =EC=93=B4 =EA=B8=80: > I would > like to explore the possibility of fully migrating entirely to a new > system. Also to reduce direct commits and instead through the online > translation tool. Cause there is the possibility of conflicts when both > are used together. Another objection of *migration* to something web-based. I had some=20 experiences with Transifex, Pootle and Launchpad before, all of them were s= ub- optimal for me than direct access to the repositories containing translatio= ns.=20 If the number of message catalogs are not large (let's say <50) then web=20 interfaces and APIs are somewhat managable. However, number of message=20 catalogs from KDE projects are thousands. HTTP(S)-based APIs are often slow= =20 when handling those large number of catalogs, especially when it comes to=20 handling more than one simultaneously. I agree with the experiences of Karl= =20 Ove regarding this. I am very okay with any number of direct commits, as long as each commits a= re=20 meaningful. This also helps tracking bug reports related to l10n, to find o= ut=20 when some wrong or offending translations had been added. Artificially redu= cing=20 number of commits is not so good idea from my side. Due to my negative experiences with translation team management when the we= b- based tools are used as primary method, I will not opt in to use any web-ba= sed=20 tool by myself and my team unless it is a must, but I won't object having s= uch=20 system if some team needs this.