Re: [faw@funlabs.org: Re: DDTP-Links on CDD tasks web pages]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[ Andreas, I have already read your apologies, thanks for ]
[ writing the e-mail, and although I don't drink bear, I ]
[ would be happy to share a table and discuss that with a ]
[ glass of coke. Now, here are some comments to try to ]
[ sort things out and advance the discussion that we can ]
[ have at DebConf. :-) ]
On 16-07-2008 18:31, Andreas Tille wrote:
> 2008/7/16, Felipe Augusto van de Wiel (faw) <faw@funlabs.org>:
[...]
> So linking to your page is no help? Are there other pages in the web
> that provide links to ddtp.debian.net? What is the difference to the
> CDD tasks pages?
Not that I'm aware of, I don't think there are other
pages linking directly to DDTP or to specific packages.
DDTSS is used to help in the translation-review cycle
to make it easier for some Translation Teams, some of them
have a only-one-review policy, others use the classic DDTP
model, one translator and three reviewers.
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.
[...]
>> would you be kind to explain what in DDTSS doesn't fulfill
>> your expectations?
>
> OK, I try to assemble of older postings worth reading if you know what
> I like to know: In short: How can I help the DDTP project reasonably.
>
> http://lists.debian.org/debian-i18n/2008/07/msg00071.html
> == I found a solution: "What do you think..."
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).
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.
> http://lists.debian.org/debian-i18n/2008/07/msg00087.html
> "Do you think that these links are doung things right or is it
> causing trouble for DDTP?"
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).
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.
> http://lists.debian.org/debian-i18n/2008/07/msg00147.html
> "I want to know whether this
> 1. makes sense for DDTP project
> 2. makes sense for the user ..."
I would say that the answer for it is: depends. :-)
Probably, some teams don't like it and some teams would
appreciate it, so doing that on a team basis could be
better.
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.
The other thing is having a page that could explain
to the user what means "fixing" a translation, the release
cycle and the other details, actually this exists in:
http://www.debian.org/international/l10n/ddtp
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. See below the idea of using an
approach similar to Pootle, the "suggested fix" idea.
> http://lists.debian.org/debian-i18n/2008/07/msg00157.html
> Explains in detail which links I use for those who refuse to read
> the HTML text which I use to link to DDTPS.
> "Do you have any more questions why I use the force option???"
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.
> http://lists.debian.org/debian-i18n/2008/07/msg00178.html
> So should I remove all the links from the CDD tasks pages to the
> DDTSS server?
IMHO, that would depend on the teams, if the team
doesn't mind, that's OK, for pt_BR for instance, I would
prefer that the "force" links were not used, and the user
would be pointed to the list or to the DDTP page on w.d.o.
Of course, the e-mail approach of sending to the
mail list a "suggestion" is similar to the Pootle idea of
having anonymous translators suggesting fixes, actually,
that could work for DDTSS, but would force us to close the
system to only "registered users", then the user coming
from CDD Tasks pages could make a suggest and without a
lot effort a translator could approve or not and the
package would not impose an extra work for the translation
team.
Actually I believe some teams would really prefer
that DDTSS were closed and controlled by the Translation
Coordinator to avoid misuse or abuse, but this is a topic
for another thread. :)
> http://lists.debian.org/debian-i18n/2008/07/msg00183.html
> "is there a chance to translate for these people or is there no such
> chance?"
I think there is, but that would depend of the
translation teams, some of them really want people to
be at some level in sync with the list and other common
practices, so a direct translation to DDTSS without
knowing why it was made would not be welcomed (by all
teams).
> Summary: I try to find out in more than 10 mails to your list (these
> are not all) whether the solution I found without your help is fine
> for you.
IMHO, the problem is that the "force fetch"
could be harmful in some cases and that some teams
would prefer to not have it being used.
[...]
>> I'm not sure about other teams, but "coordination"
>> is always appreciated, so simply "fixing" a description
>> without discussing it before is not exactly the best way
>> to go, if there is a different consensus, loading the
>> description would simply mean re-reviewing it to get rid
>> of it from the "working to do".
>
> Please accept that I desperately trying to find out how I could
> coordinate with you how to fix a translation. Please trust me that
> I'm able to detect and fix simple spelling bugs in my mother language
> which even a simple spell checker would have detected. Could you
> finally be so kinf to explain me the right way to go if I want to get
> this fixed? Is this question to hard to answer?
I hope that I could make it clear why we are
concerned with the "force fetch", the problem is not
the "real user trying to help" but the collateral
effects of reloading packages already translated
without knowing why.
That's why I was imagining that pointing the
user to a place where he could voluntarily force the
fetching of the translation could reduce the impact,
because the chances the he actually fix it instead
of just click and "ooops, I didn't expect that to
happen" would be reduces (also would avoid the crawlers
like search robots).
>> If it is a "hit-and-run" fix it might not be desirable. :-(
>
> Why?
Because sometimes it is not a proper fix. I'm not
talking only about fixing a typo, mistype or mispell,
sometimes people wants to change the wording and that could
break the team practices. I'm not saying it is bad, but I'm
sure some teams are not interested in such reviews.
>> Tell them how to use DDTSS and how to contact the
>> translation teams to coordinate their work. There is some
>> discussion about adding a "header" for the translation
>> pages that could be used by the translation teams as an
>> information point to new translators.
>
> My way of telling them was linking to
>
> http://ddtp.debian.net/ddtss/index.cgi/${lang}
>
> and filling in the parameter known as "Fetch specific description".
> Before I did so I started a query here on this list and asked whether
> this is the right way to tell them. Do you think that I should share
> the experience to ask questions here on this list with other volunteer
> translators? (I'm sorry if I sound angry - I am angry which is not my
> normal temper, but I can not help currently.)
Actually, that is what I was imagining, but the
rules can vary from team to team and we know users, most
of them wouldn't read the "common rules" or wouldn't be
in sync with the users (but that is also a different
problem). :-)
Once, I imagined that we could add a "stats"
area for CDD, that could have the links and that could
be used as some sort of central point, like we have
for the package priorities and POPCON500, but that
won't address the problem of "trying to fix a
translation", so the "suggest a fix" seems to be
better.
>> I just pointed
>> out that ddt.cgi has a different interface from DDTSS
>> that might be what you are looking for, after all, DDTSS
>> used ddt.cgi in the principles, now it is integrated.
>>
>> You want to fix a broken translation, just do
>> what we do, load it into DDTSS and fix it,
>
> I think I do so and my question is: Is the way I'm doing it the right
> way. I did not yet got a definite answer.
I believe there is no "Right Way(tm)" in this case,
what seems to happen is that the "force fetch" is perceived
by some of us as something evil if not properly used, so a
simple answer is quite hard, as I said, some teams might
appreciate that, some teams might not.
>> Now, imagine if you link to a package using
>> "force fetch" and people just click to see it, it will
>> load the translation without nothing to fix, it is not
>> about "fixing' things, it is about reviews unnecessary
>> files (and some teams have only one or two people).
>
> Well, because I did not know which effect force might have I was
> asking. There was until now one single answer
>
> http://lists.debian.org/debian-i18n/2008/07/msg00180.html
>
> which says "I understand andreas" (pew) and "put all 'klicks' on the
> pending list and this add a load to the ddtss translators." So should
> I or should I not remove the links from the CDD tasks pages? But
> please explain in how far this is different than filling the form in
> the very same way.
Filling the form is not susceptible to "click
accidents" or "search engine web crawlers", and right now,
as I said above, "force fetch" is perceived by some of us
as something "evil" if misused, we don't really know the
impact of CDD Tasks pages on DDTSS, it might live pacific
without giving translation teams any extra work, but what
most of the people that opposed to the idea have in mind,
is the common sense to avoid overloading translation teams.
[...]
> Once again: What is the correct way to go if I see a description
> translation with several spelling errors?
Unfortunately I don't think there is a common
approach, if a user is able to access the DDTSS and fix
it, adding a comment like that seems very helpful.
For pt_BR we use a standardized comment:
YYYYMMDD: author: action
Like:
20080718: faw: translation.
20080718: faw: review. Typo fix and improvement of foo.
For most of us, it is bad if:
a) An already translated package is reloaded without a reason
b) An already translated package is changed but the changes
were not obvious typo fixes and there are no comments
But it is pretty good if the package is reloaded
with a typo fix, even without any comments, so rethinking
the whole discussion, it is a balance between good things
and collateral (bad) things that could affect the teams.
The idea of "suggesting fixes" seems the best way
to go, but it is not implemented right now in the DDTSS
side. :-(
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.
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
iEYEARECAAYFAkiA61IACgkQCjAO0JDlykY1AQCfbmZzUdgCykkN4s0SNhC0iohB
FFkAoI3W1BtSj6SgwCi+KK5NE/gkeNMv
=vrod
-----END PGP SIGNATURE-----
Reply to: