[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Please, stop abusing ddtss/DDTP



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 15-12-2007 23:09, David Paleino wrote:
> Il giorno Sat, 15 Dec 2007 22:59:19 -0200
> "Felipe Augusto van de Wiel (faw)" <faw@debian.org> ha scritto:
>> On 15-12-2007 22:13, David Paleino wrote:
>>> Il giorno Sun, 16 Dec 2007 00:00:13 +0100 Martijn van Oosterhout ha scritto:
[...]
>> 	As we told you before, your script parses the DDTSS interface
> 
> Wrong, it doesn't. -.-'. Should I explain you again? The statistics are drawn
> by parsing Translation-<lang> files. Not DDTSS. Seems like we're speaking
> different languages here. And this makes me worried :'(

	Ok, let's align our terminology, by parses we mean that you
access the pages with the wrong purpose, it doesn't really matter
what you do with the result of it, what it matters is that DDTSS
has a different goal then what your script was doing.


>> and that fetches files
> 
> ...just not to have a "description not found" page.

	And by doing that you penalize several teams. So put this
"just" in perspective here, to make it comfortable for potential
translators you make it _very_ painful for daily translator, even
more harder for small teams.


> What I'm asking is just a "edit.cgi?package=<foo>" script which checks if the
> description must be fetched (and does it), otherwise points to the edit form.
> It doesn't seem that difficult :(

	What we are trying to tell you is that if you want a nice
interface group by package (or type of packages) where translators
should click and get a package, then you should use DDTP/DDTSS
infrastructure.

	Some teams control their priority list, speaking for pt_BR
for instance, I do not want the med packages to popping up because
a $RANDOM script feels it is the time to fetch it. I understand
that you want to provide an easy way for a single click to get the
package, but the i18n Team are in the middle of trying to *integrate*
the tools and provide a common infrastructure, centralized, we really
do not have the interest of having distributed parts, we are moving
away from this model.


>> 2) Debian-Med wishlist
>>
>> 	Bring the features Debian-Med wants to DDTP/DDTSS so we
>> 	can provide this service to other projects, like
>> 	Debian-Lex and Debian Science.
> 
> In fact, my script wasn't intended to be Debian-Med's only. In general, we're a
> "prototype" of what other CDDs could use in the future.

	Good, so let's make a better prototype, because right now
the script is harming more than helping.


>> 	As I said, we can work to provide that kind of list on
>> our side, some sort of "group package" feature,
> 
> That shouldn't be a list; that would require a bit more work of just the
> "edit.cgi?..." I was mentioning before.

	Not really, we can pretty easy group the packages on our
side, you just need to provide the list. After that, we can even
work on some sort of interface to update such list.


>> that could allow to see the statistics, using the DDTP backed in a much more
>> elegant way. The DDTSS was not designed to be used as a interface
>> to "summary tables", it can be expanded without doubt, but it
>> sounds much more interested to have "summary tables" merged in
>> our infrastructure.
> 
> Sure. But this would be a future wishlist item IMHO; it's not desired by
> everyone (AFAICT, only Debian-Med is using such a feature right now. Would it
> deserve the effort of integrating it into DDTSS' infrastructure?)

	It is the desired of the people behind i18n infrastructure
that we add features in the core so it make easier for future use,
so if we can integrate it now and avoid given more unnecessary work
for translations teams, that's definitely our choice.

[...]
> P.S.: I understand that in some sentences I might sound rude; please forgive
> me, it's 2.09 am here, and I'm not that able to rephrase my thoughts ;)

	No problem, ASCII communication is not very good and
transmitting the feelings and nuances of voice, we find the
Debian-Med idea interesting, and we want to provide this
service, but right now, we do think that there is a better
way to do that.

Kind regards,
- --
Felipe Augusto van de Wiel (faw)
"Debian. Freedom to code. Code to freedom!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHZKO+CjAO0JDlykYRArkPAJwLGRfyjz7Nyyk+o87m16L56szHYgCfZ1vC
dK5JJxAJEusMzA9tLoRiAgU=
=mZ+W
-----END PGP SIGNATURE-----


Reply to: