Re: [faw@funlabs.org: Re: DDTP-Links on CDD tasks web pages]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 19-07-2008 13:55, Andreas Tille wrote:
> 2008/7/18 Felipe Augusto van de Wiel (faw) <faw@funlabs.org>:
>> I can speak for the Brazilian Portuguese team, we do
>> that in coordination with the rest of the team thru the mail
>> list, so every single contributor is required to subscribe to
>> the Team's mail list, adopt our practices and discuss the
>> changes, specially when revising already translated descriptions.
>
> I can only speak from my own point of view and it is not really related
> to the original topic: I would love to help out with *some* translations
> but I would definitely not subscribe to another mailing list to be
> able to provide the translations. So requiring people to subscribe
> to a mailing list means to ostracise them.
We use pseudo-urls, so *most* translations are handled
using the mail list, if somebody doesn't subscribe it has a
great chance to duplicate the effort. DDTSS is a little bit
different, but again, terminology and other decisions happen
on the list, if you are not subscribed, you miss them and have
twice as much work. :-) But that's pt_BR's case, other may
have different workflows and we don't "ostracize" them, on my
experience, most of non-subscribers "lost" their work because
they translated something already translated or updated but
that was pending. :-(
>> So, here is the "force thing" that most of us are
>> afraid of, mainly because it can be harmful if the user is
>> the type of hit-and-run. If the "direct link" forces fetching
>> the translation and the user thinks "oops, I was not planning
>> to do that right now", it already reloaded the package
>> description and the rest of the translation team have to review
>> it without any modifications (and without knowing why it was
>> reloaded).
>
> Are there any stats that since about two weeks more such
> reloaded package translations are in the database?
Not that I'm aware of, but they "keep popping up"
on Brazilian Portuguese pending list without any
modifications and fully translated, and I got at least
one complain per week from the translator about the
"repeated bio packages" (as they call it).
>> Just to be clear, there are multiple scenarios that
>> we should map and discuss: (a) load the translation without
>> doing anything; (b) load the translation and fix something
>> that the rest of the team disagrees; (c) load the translation
>> and fixing a real mistranslation and/or typo. Those are the
>> three main use cases, but there are other corner cases.
>
> Yes, we have these three cases. But a) could be easily handled
> by technical means as Grisu suggested: Just drop the unchanged
> text from the database and no harm is done. I could also imagine
> a simple solution for
But it needs to be done, right now it is not ready. :-(
> b): Create a diff, send the diff to the mailing
> list - if it is accepted an easy mechanism could be implemented
> to declare the translation valid. IMHO this is not really a big
> deal.
That seems more "conservative", in the future it could
be implemented on DDTSS side like the "suggest feature",
similar to Pootle.
>> This is about the difference of using "force" to fix
>> the translation and to "fetch" something that is untranslated.
>> It works, the problem that some of us identify:
>>
>> i) Crawlers could follow the "force" links and keep reloading
>> the translations, because there are some nasty robots, of
>> course we can block them, but after the initial load already
>> happened. (like GoogleBot).
>
> I understand one of the previouse mails that way that the bots
> are kept out here by the intermediate page. So I would like to
> see some stats that the existence of the links to DDTSS increased
> the number of wrongly loaded pages significantly. Could somebody
> please be so kind - then I would immediately take action and
> remove the force links to avoid extra work for you.
We have more than one way to try to kept the crawlers
out but once they hit us it is too late, that's why we try to
avoid giving them any chance. :)
>> ii) The "translation abandoned" behavior, somebody just clicked
>> to see what happened, either translated or non translated
>> packages. Not that it is harmful, but it can made packages
>> popping up without knowing why.
>
> I'd rather call his a bug in the server software if something pops
> up that should not.
If somebody asks for a translation it "pops up", it is
not a bug, it is how DDTSS works.
[...]
>> What I think is that maybe we could use an approach
>> proposed by Michael (grisu), have a page that doesn't do
>> anything unless somebody changes the description, then it
>> loads the package description in the DDTSS queue.
>
> Yep. I wonder why this is not the case - I'd regard anything else
> as a bug that should be fixed in any case (independently from our
> issue).
If you ask for a package and it is translated, them it
says so, if you use "force fetch", then it comes and even if
you "don't change anything" it appears on the pending translation,
after all, you required it, and it is quite handy to load tasks
for others in the team, so it is not a bug.
[...]
>> A third option would be to have an e-mail form, the
>> user "fixes" something and that is sent to the mail list to
>> be coordinated by the translation team, that could actually
>> work for the teams that don't want direct changes in DDTSS
>> without coordinating first.
>
> I have to think about this. My experience with calling a MUA from
> a web page to generate an E-Mail is not really positive. But the idea
> to generate an E-Mail somehow that enables the user to use the
> DDTP mail interface was mentioned in previous mails of mine.
My idea is not exactly use the DDTP email interface,
I was thinking about sending the "suggested fix" to the mail
list so people can react, fix and reply, this works for
people that don't want a deeper attachment with the
translation team (which in my opinion is not good, but it can
happen).
>> The use of the "force" option is clear (at least
>> for me) and it really does what it is expected, force the
>> already translated package to be fetched. One of the
>> concerns is that should happen only if really needed, not
>> discussing if a "real user" tries to improve a description,
>> but of all other cases: "just click to see what happens" or
>> web crawlers (again, I'm speaking about search engines of
>> SPAM crawlers following links) forcing loading already
>> translated files.
>
> Martin, could you confirm that the page that is loaded inbetween
> works effectively against crawlers or not? I perfectly understand
> the issue and if there is any evidence that those crawlers do some
> harm I'll immediately remove the option.
They do. :-(
It is not like we are doing that because we are
stubborn people and we don't want that, is just that it
is unsure right now if this is desired by all teams, as
the "force fetch" is perceived as "evil" when not
properly used by people knowing what they are doing, so
I would say that the best right now is remove them and
wait until we can provide the technical resources and
features to deal with this new demand.
>> ...
>> that won't address the problem of "trying to fix a
>> translation", so the "suggest a fix" seems to be
>> better.
>
> I'm perfectly fine to tag the translations done by anonymous
> translators (from wherever they are coming - you can not tell
> whether they found DDTSS by chance or by a link from a CDD
> page) as "suggest a fix". We just need a technical means to
> tag it this way (wishlist bug to DDTSS?).
Yes, sounds the course of action right now.
[...]
>> For pt_BR we use a standardized comment:
>>
>> YYYYMMDD: author: action
>>
>> Like:
>>
>> 20080718: faw: translation.
>> 20080718: faw: review. Typo fix and improvement of foo.
>
> Sounds great. IMHO also a wishlist feature for the CGI script:
> - Date can be added automatically
> - Separate Author field - if this field remains empty set a
> anonymous flag that requires extra validation
> - translation / review can be also decided automatically by
> the server software
> - Advise the user to add a comment
This is the comment field and it is "open", other
teams have a different approach regarding the use of this
field, we have concerns about registering the contributors,
specially because of legal aspects, but this is also
>> For most of us, it is bad if:
>>
>> a) An already translated package is reloaded without a reason
>
> Sure, but as I said there is a simple option to deal with this and no
> reason to talk about this - just fix the bug in the server software.
As I said, there is no bug in the server software,
sometimes we want to force loading some translations to
fix things that were discussed in the mail list. It can
certainly have a different approach and be improved to
handle more events and options, but it is also certainly
that it is not a bug.
>> b) An already translated package is changed but the changes
>> were not obvious typo fixes and there are no comments
>
> A diff might do well here to decide quickly, right?
We have a wdiff, but sometimes they don't make
any sense, and usually it happens because people are not
in sync with the rest of team.
>> The idea of "suggesting fixes" seems the best way
>> to go, but it is not implemented right now in the DDTSS
>> side. :-(
>
> ... well, there is DebCamp, right? ;-)
Well... yes, but certainly there are other pending
tasks with different priorities.
>> I hope this clarifies the details and help you to
>> determine the best course of action, and of course, we
>> can have a brainstorm and some discussion regarding this
>> during DC8.
>
> Yep. My decision is: If there is the slightest evidence that the
> force option on the CDD pages just has triggered any harm and
> has increased the number of unneeded reviews significantly
> I'll drop it just now. Please tell me immediately. If there is no
> evidence we try to continue this discussion at DebConf (DebCamp -
> I'll be there at 6.8.).
Please, drop the "force fetch" for now until we can
provide the resources necessary to deal with this new use
case.
Kind regards,
- --
Felipe Augusto van de Wiel (faw)
"Debian. Freedom to code. Code to freedom!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkiD9gQACgkQCjAO0JDlykYT5ACbBC4lmRUyYxyK1ZzhCcQ+hgCg
v5EAn20J3PdRBz1OBVhdA3RO/Sr7YtE2
=GR4W
-----END PGP SIGNATURE-----
Reply to: