Hello!
I understand Hartmut very well, but I also understand several points of the
others.
I think we all here have at least similar aims (if not the same) concerning PHP
and it's Documentation.
Since I'm not experienced enough (yet), I don't talk about the "HOW to realize"
for now, but
I want to focus on the - IMHO - two main-issues (instead of fighting about one
single proposal with a great aim):
1.) We should have in mind the average user - also a beginner - which downloads
a documentation. If he finds it in his native language, he'll DL it. He wouldn't
ever think that it might be not complete. So a missing function in the doc
doesn't exist in the language.
-> We really should care that all functions are available in each
laguage-version of the documentation (no matter if English or already
translated). If you do it via a script, splitting up files, shouldn't really
matter, if most of you are against file splitting, make another proposal, or do
the script-change (or tell me how I can lean it, and I'll do it).
2.) Resources for Open Source projects:
iX, a German magazine, brought it to the point: A big issue for Open Source is
the motivation to get enough resources.
And a voluntary translator should be rather immediately able to translate text
and not - extremely spoken - being forced to study computer-science before.
--> I'd suggest to invest a one-time-work in a step-by-step tutorial for the
needed environment, to prevent the giving up of an possible translator only due
to technical problems before he has done anything useful for the Project (The
same is with being ignored: Egon told me I should apply for an CVS-account, but
done this, I've been ignored completely - not even a "rejected").
If you talk about CVS and download-sizes:
Here we should also have in mind the person, the resource we want, and not what
the "applicant has to do" (there are enough other technical necessities). So it
it's possible for the moment to minimize the DL-size with CVS-commands, why not
again write a step-by-step-tut?
But pls. have also in mind for the future, that the number of languages could
grow as well as the number of additional files in the existing languages (not
yet translated files, etc. -> more MB).
To make a long story short:
Please don't "beat down" one single proposal, but think cool about the
user's/translator's needs and about possible ways to realize them (M$ is only
that big, because it was able to motivate users to buy, and also motivate people
to work for them. And they motivated People and magazines to advertise for them
{not like the last PC-Magazine-Article about PHP}).
I think with that focus in mind we can only win!
Best regards,
Thomas
Hartmut Holzgraefe wrote:
> [EMAIL PROTECTED] wrote:
> > > > but the average translator might not be up to that level
> >
> > But I hope you can learn enough :)
>
> it is not the point if somebody is able to,
> it is about the question whether he'll be willing to ...
>
> > > > and reducing the checkout size from ~25MB to ~6MB for the pure
> > > > english manual and about ~10MB for a complete translation
> > > > with the additional benefit of faster updates could be a good start
> >
> > I have checked the PHP manual on toye and it tooks only a very short time.
>
> once again i'm not sure if you got my point here
> the time a cvs update takes depends on the number of files
> even an update that wouldn't apply any changes will create a very high
> CPU and network load as soon as the files modification timestamps have
> changed on the client side ...
>
> > I have also a very old modem with 14.4 kB. You can stop a checkout and use
> > the next day a update until you have a complete repository.
>
> this is exactly what the average user *doesn't* want, especialy
> when 75% of the stuff is of absolute no use to him
>
> > > i can say nothing about the technical background nore the performance,
> > > the building of the manual and so on.
> > > the "missing functions" problem led me to help with translation.
> > > solving the problem of "missing functions" in any way would be great!
> >
> > Look at the functions tables from Hartmut and you can get some idea what
> > we are speaking. www.zugeschaut-und-mitgebaut.de/php/ oder
> > zend.com/phpfunc
>
> the tables show the translation status of a function,
> but the will (at least for now) *not* show wheteher an untranslated
> function
> will show up in english in the translated manual or not at all
>
> as long as the xml containing this function isn't translated the
> untranslated
> functions will show up now, as soon as a file *is* translated every
> function
> added to the original english file after translation will *not* show up
> in
> the translated version
>
> that's the problem i was talking about, and not the fact that some
> functions
> are translated while others are not
>
> > > just the opinion from a really novice without any knowledge of the
> > > whole technical stuff.
> >
> > Please don't split the manual into several languages. Andrei have told us
> > that even a novice can checkout the language he is interested in.
>
> especially a novice should have to care about all this as little as
> possible
> the solution suggested by Andrei may lead to problems as it does not
> only
> affect the way you have to checkout the manual but also you have to take
> care
> not to use the '-d' option on updates while a manual + translations as
> seperate repositories will only need one additional step on checkout
> (and only for translators, not for people working on the original
> documentation)
>
> > Witthout the root directory the manual is useless.
>
> sure, no question, but how does this fit into the discussion we have
> here?
>
> manual writers need the infrastructure + english original files, theese
> will both stay in the original repository
>
> but the usual manual writer will only need this and none of the
> translations
> (which right now make up about 75% of the manual sources. with all
> translations
> done it would even be more than 90%, and every new language added will
> increase
> this further)
>
> and the usual translator will need the original manual plus his language
> of
> choice, but not the other 10+ languages
>
> --
> Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77
