Re: [DOC-HU] RE: [PHP-DOC] RE: [DOC-HU] PHP DOC BUILDS -- PLEASE READ

> > Some criteria was establised for this. AFAIK it was said that it
> > checks for
> > language-snippets.ent precense, when deciding whether a
> > translation should be
> > built. BTW this file is the on translations are started with, so
> > it may not
> > be the best to check for... Maybe a sum translated size check?
>
> perhaps... i was going to go for a human aspect here... if xyz
> 'experienced' phpdoc'ers were to agree a translation was ready for build,
> they could add it to a file, or something.

OK, a file listing translations to be built seems all right.

> > Both of these would enourmously speed up the generation, so all languages
> > would be built in one day. Problems with this include inconsitencies
> > appearing in:
> >
> >  - TOC parts
> >  - Prev/next links
> >  - Any type of <xref> crosslinks
>
> Right, my idea would be to try and build in a sandbox with existing
> content, and then simply update what has changed. Hmm, this might be
> possible if we were able to use cvs in a smart way (ie, checkout files
> changed since a certain date/time)... we could get an idea of what changed.

You can have a list of last change times of files checked out initially. Then 
you can query the status of files in CVS (including last changed date), so 
you can detect, whether the file is new.

> Working in a sandbox of already built en... and just updating what needs
> updating, rather than starting from the beginning. If all the links are the
> same (and theoretically, they should be, they are after all just
> translations) then everything should dovetail into place...

We are lucky enough to have many XML files, so if a functions description in 
changed, then one XML file is changed, and one HTML output file should be 
generated. The very perfect thing would be to combine the above with the 
separate TOC generation I mentioned about the big phpweb files. So:

 - build en HTML files (with placeholders in place of TOCs
   and prev/next links)
 - build TOC for en files (to a php structure, ie. array)
 - build individual files for translations (with placeholders)
 - update TOC file with new titles built
 
The final English files can be generated after the second step, the final 
translated files can be generated after the last step. Both with generating 
TOC and prev/next information in place of placeholders.

So the idea is to put the problematic information to another level, and only 
deal with really independent content on the build level.

The problem remains is the links. If you build one function XML file, then it 
won't be able to determine, what HTML file will contain the part linked in 
the crosslink. We can overcome this, if we state that we only have HTML files 
named after their IDs, so all internal links should point to the 
corresponding HTML files. This is not true however in all the cases (ie. 
parts without their own chunks on reference pages for example).

Goba