> What will you do with maintainers (responsibles) for a particular
> file if he is inactive for 15 months and two weeks. I can see this
> in the German documentation (look at [en|de]/functions/pcre.xml and
> de/Translators). There is a maintainer for the German version and
> nothing happens.
The hu tree is maintained by me now, it is true, although
we have Kontra Gergely, with a "kgergely" CVS account,
and one of us, Heilig Szabolcs also requested a CVS account
recently.
But, for the "hu/language" dir, the files were translated
by "kgergely", but he didn't have time to take care of
the files, so I am the maintainer of those files now.
I have inserted a comment in the files that the original
translator is Kontra Gergely, but I was the maintainer
of those files for some months now, as I had the time.
So the simle answer is take the file from the maintainer
and add it to a person, who have the time.
> > The script walks through the en dir in phpdoc and tries
> > to find the corresponding files in the translations dir.
>
> And what will your script tell you. Hartmut looks into every
> <refpurpose /> element and looks for differences. If he could
> detect a difference, he assume that this particular file is already
> translated. The scripts from Hartmut will mostly fail if someone
> translate only one function in this particular file.
Because we have Hartmut's configure script, autodetecting
the missing files in translations, we have a practice of
placing only the translated versions of the files to
the translated (eg. hu, or nl, or other) directory, so
this revcheck.php script does nothing to figure out if the
file is translated or not. If the file is not there it is
not translated, if the file is there, it should contain at
least some foreign language text... And shoul contain a
Revision comment if we use this system.
> > There are lists for untranslated files and files without
> > revision comments.
>
> If you validate a special language (except en) you can see a list of
> untranslated files. I don´t know what we will gain from revision
> comments.
I can't get what you exactly mean "validating" is. If you do
a configure --with-lang=hu the script prints out the missing
files, it is true, but it is not really useful for updating
purpouses IMHO, as the output of revheck.php (revcheck.html)
is better to store this information permanently. Although
this is only a side effect of revcheck.php, it is focused
on handling the Revision commments.
> > The best thing is the colored revision table, where you
> > can find all the information as in /~rasmus/status.php,
> > but many more:
> >
> > - the exact revisions, and number diffs
> > - some size diffs (not exact, as the en and <tr> languages used)
> > - date diffs (this is the only one that /~rasmus/status.php
> provides)
> >
> > A real world example is attached (the actual hungarian files).
>
> I think revision numbers and comments are not sufficient.
So you think the date diff is enough (as in the
/~rasmus/status.php script). But think of it a bit, if
you have the revision number of the english file used
to make the translated file, you can make an exact diff
from the actual english file and the english file used
to translate the file. With only dates you are unable to
do this.
The links on the revcheck.html page are actually those DIFF
links. Following these links you exactly know what characters
are modified since the translation in the english version.
If you update the translation, the only plus thing to do
is to modify the revision comment, to reflect the new
version number.
> It may be working in the hu tree, there is only one maintainer :)
Currently there is only one active maintainer. I hope
it will change in the near future, as the school begins,
and most of the translator people have permanent access
in universities to the net.
> This would not work in the German manual, because we have many
> maintainers and not every maintainer is active. So the only solution
> to this dilemma is, every translator have to lookup the changes
> (cvs.php.net) in the en tree back to the time the translation was
> modified.
The revision comment is the thing that helps in this situation,
as it specifies the exact revision number when the tranlation was
made. You can convert it to a date, if you would like to count
with dates, because there are exact commit dates for all revision
numbers.
You say, translators need to find out that date somehow,
I say it can be stored in the file itself as a Revision number,
so it is much easier to start updating with the exact information.
Therefore we get more actual translations and nothing is left
out...
It is true, that for files where you do not know the revision
number (we also have some in the hu tree), you need to operate
with dates, or better you can read all the file and paralelly
the actual english file, and update things. But from this time,
you can work with the Revision number.
The revision comment syntax is designed to hold the same
information as we use in our Translators file currently.
See phpdoc/de/Translators, what is there
- Maintaner
- Status
- Revision number (eg. bis V 1.12)
The same is in nl/Translators or it/Translators. Revision
comments are just a way to make this more convinient, without
the need of allways altering an external file. With these
comments, we also have a unified syntax, so a script is written
to process the files and make a clear table of needed updates
and translations.
> There have been discussions to split every
> file in files which contain only one function description. But if we
> can do this we should reorganize the function reference first.
I agree on doing the reorganization (with categories) and the file
splitting, hope so we can agree on this with the other people here.
Goba
