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

Re: [faw@funlabs.org: Re: DDTP-Links on CDD tasks web pages]

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.

>        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?

>        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 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

>        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.

> 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.

>>   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.

Well, this is an issue to discuss at DebConf.  IMHO we should find
a technical way to serve all teams equally.  While I could implement
a solution like "For lang A do this, for lang B do this and do that
otherwise" - but I fail to see an objcetive reason why I should do so.

>        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

>        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

Thanks - I'll put this into the footnote of the pages in any case.

>        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.

>        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.

> ...
> 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?).

> is the common sense to avoid overloading translation teams.

That's obvious and not intended!  I really regard your work.  It
is really useful and I would really like to avoid to do any harm
to you.

>        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

>        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.

> 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?

>        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? ;-)

>        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.).

Thanks for your verbose input

         Andreas (happy to see the flames erased).

Reply to: