Re: New PO Template file for `gnuash'

El mié, 30-10-2002 a las 14:35, Martin v. Loewis escribió:
> Carlos Perelló Marín <> writes:
> > One translator can fetch a .pot from your ftp 
> This is unlikely: they would need to know where, inside the ftp, this
> POT file is located. More likely, they download the POT from the Web,
> and there they cannot avoid seeing the external translations.
> Bug let's assume that happens...
> > and send it to the robot without look at your web pages.
> The robot will refuse the submission, telling them that they are not
> the assigned translator.
> > It's the same problem that with cvs. Perhaps the robot will reject
> > the translation, but the translator has lose his time translating
> > it.
> Yes, but the translator does that only once (for one
> project). Actually, most translators in the TP do that *never*: they
> may translate what is recorded as unassigned and untranslated. I know
> of no case where translators started translating without first
> verifying that there is no existing translation, using the established
> procedures for checking.
> Now, the established procedure for checking with the TP allow for
> external translations. If the established procedure for Gnome-i18n is
> to look in a certain directory in CVS, then this directory should
> feature some notice, e.g. a README file.

will you update both list the one at and the other at TP ?

what happens if a translation does not exist and a gnu translator starts
the translation and at the same time a gnome translator do the same?

I'm not telling the problems with the GNOME way and the GNU way, I'm
talking about the problems we can have if we use both teams for the same
module. I's more easy that a GNOME translator joins the GNU team or GNU
translator joins the GNOME team that we try to work together with our
own tools.

I will only agree to work together if we look a way to integrate the
robot and our cvs (the robot gets a file do all checks and then commit
it to and automaticly fetchs .pot snapshots. The robot
should be able to manage dated versions).

> > How will you comunicate my status pages with your robot so both will
> > know that one modules is available to translate because the old
> > translator is not working on it anymore?
> I'm not sure I understand the question. That the translator is not
> working on it anymore is not sufficient. The previous translator must
> either explicitly say that she won't work on it anymore, or must be
> declared unresponsive by the team leader.

we have a really high number or translators and modules to translate so
we "declare unresponsive" a module automaticly if it takes about 3
months without an update (for the spanish team and other ones work this
way), of course, before we start to update that translation, we send an
email to the old translator and to the mailing list telling that we will
start to mantain this translation.

> When either of these happen, the TP registry will be updated to make
> that particular domain unassigned. If you want to, we can establish an
> automated notification channel.

Perhaps sending an email to the mailing list for that language it's ok.
But what happens from our side?, until we don't have a new translator
for that module we cannot say that it's unassigned...

If we should change our way to do the translations, I think that we
should do it with a good solution and not use a patch to integrate us
with the robot.

The robot is a good idea, but if it's extended so it can work with CVS.
If not, I think that the extra work that we need to do to work together
is not needed for only 2 modules (gnucash and gthum).

Also I think that the affected translators should give us their


> Regards,
> Martin
> _______________________________________________
> gnome-i18n mailing list
Carlos Perelló Marín
Valencia - Spain

Esta parte del mensaje esta firmada digitalmente

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