Recursive XInclude support and some automatix fixups for translations

[alfsb]

This is a quick fix for the newfangled recursive XInclude usage in manual. It runs xinclude() in loop for libxml versions < 2.11, and does a few automatic fixups, to avoid breaking all translations at almost any new XInclude usage.

Fix doc-en and almost all languages in my machine. Fails are: doc-tr because it references an xml:id "filter.filters.sanitize" on language-snippets.ent; same on doc-uk. doc-it and doc-ro seems to be effective dead (more than six months without local activity, files several years old)

[Girgias]

Seems like me merging the other filter PR fixed a bunch of the broken languages, nice.

The other thing, is that it seems that this might be a libxml 2.10 issue only, as @SakiTakamachi was able to build it fine using libxml 2.9

[alfsb]

I can push a new change that includes looping on xinclude() for broken libxml recursive XInclude support, so the code will work on many libxml versions. It was controversial, so I left it out at the last moment.

The residual failed XInclude thing (this PR), is unrelated to libxml version.

[Girgias]

Apparently the recusrive Xinclude affects version prior to libxml 2.11 quite randomly :|

But this looks fine to me, so feel free to merge.

[cmb69]

If I understand this patch correctly, it adds empty title elements caused by missing title elements due to erroneous xincludes. Shouldn't we fix the root cause instead?

[alfsb]

Apparently the recusrive Xinclude affects version prior to libxml 2.11 quite randomly :|

Pushed a new change, an for surrounding xinclude(). I think this will resolve the random aspect for now.

[alfsb]

If I understand this patch correctly, it adds empty title elements caused by missing title elements due to erroneous Xincludes. Shouldn't we fix the root cause instead?

Yes, of course. And configure.php will complain about the failed XInclude. But after the warning, then there are two options:

• Break all translations;
• Keep translations building, albeit with warnings.

That is, to make XInclude failures a hard error on translations as they are on doc-en, or to keep them as warnings, as they are now. Making they hard errors will break all translations, almost instantly, at each new Xinclude added on doc-en.

[alfsb]

@cmb69 you are a Windows user? Can you test if this updated PR resolve the building failure with or without updating libxml local version?

[cmb69]

Yeah, with this patch I can build doc-en where it would without it.

However, I still don't think that making excessive use of xincludes is good for maintainance reasons, because you are not aware if any sources you are modifying are xincluded from somewhere else, and it's probably almost impossible to find out. So you make changes to the sources, which are then reflected on other pages which may not be supposed to also show the new information. It get's worse with nested xincludes.

[alfsb]

But this looks fine to me, so feel free to merge.

Sorry for the push after the review. I pinged all people of # 4163 to see if this resolves the two issues in one go. If yes, this will supersede php/doc-en#4214 (but also delay #187).

This passes all langs on CI (besides doc-it), but let's see if passes on translators machines as well.

One thing I noted is there is no emails of build breakage in this case. There is none on build machine? Previously I would inspect http://doc.php.net/logs/ , but it does not work anymore after server migration.

[alfsb]

However, I still don't think that making excessive use of xincludes is good for maintainance reasons

If XInclude infrastructure becomes too complex, #183 (comment) may be a solution, as it makes having small to big XML Entities way easier than it is now. Yet, I linked into the specific comment where I wrote about how Manual PHP is already at the limits of libxml capacity.

Another way is using an specific convention for XInclude targets of manual, that will make more easily visible that some parts of manual are expected to be replicated.

[alfsb]

Merged. Let me know if are any problems. This was a semi-random problem, after all. Tested few minutes ago:

$ time ./ball.sh 
  en
Running XInclude/XPointer... 1 2 done. Performed 1544 XIncludes.
All good. Saving .manual.xml... done.
  de
Running XInclude/XPointer... 1 done. Performed 1522 XIncludes.
All good. Saving .manual.xml... done.
  es
All good. Saving .manual.xml... done.
  fr
Running XInclude/XPointer... 1 done. Performed 1528 XIncludes.
All good. Saving .manual.xml... done.
  it
  ja
Running XInclude/XPointer... 1 2 done. Performed 1496 XIncludes.
All good. Saving .manual.xml... done.
  pl
All good. Saving .manual.xml... done.
  pt_BR
Running XInclude/XPointer... 1 done. Performed 1541 XIncludes.
All good. Saving .manual.xml... done.
  ro
  ru
All good. Saving .manual.xml... done.
  tr
All good. Saving .manual.xml... done.
  uk
Running XInclude/XPointer... 1 2 done. Performed 1517 XIncludes.
All good. Saving .manual.xml... done.
  zh
Running XInclude/XPointer... 1 2 done. Performed 1532 XIncludes.
All good. Saving .manual.xml... done.

real	3m32,671s
user	3m4,781s
sys	0m21,135s

XInclude curiosities: doc-en need 2 rounds to fully resolve, doc-de need only 1, and so on. Languages without counts have XInclude/XPointer failures.