> > It would be nice if it did this opposite of this as > > entities.php imho wouldn't be useful in 'make test' > > as it's not a big deal to have unused entities in > > there. But it is a big deal to use entities that > > are not declared! Do we have a script that tests > > this?
Yep, scripts/missing-entities.php does this test, and tries to add missing entities as entities with the "???" content, so they don't stop the build process. This does not work correctly in all cases for some reason (like for the language-defs.ent, for which I have added a different EN fallback fix). What missing-entities.php does is to run nsgmls on the configured manual, and tries to grab all the missing entity names from the error messages. So it is similar to a "make test" which is processed, and the entities are autogenerated to make the build work. So if this would work all right, we would have a system to create entities as needed and echo warnings out from the build system in case a legacy entity is used. So if we go on the automation way (which we should :), then missing-entities.php is the starting point I think. But as I said, it does not work correctly for some reason in some cases, so it needs to be debugged... > My intention was: run entities.php on the en-tree to produce a legacy.ent > from global.ent. Move the unsused entities in en from global.ent to legacy.ent. > This forces to end up all unused entities for the translations in > entities/missing-entities.ent. > The implication: all entities in global.ent should be used in the > manual, means we can't have entities in this file we don't actually use > or plan to use :-) Yep. > I think translators never look at missing-entities.ent :-) Yep, sadly... > > I think we all should help give Goba time to create the > > legacy.ent, what can we do to help Goba? :) > > +1 Well, the first steps are easy. First the set of legacy entities need to be defined. This means, that someone needs a full checkout of *all* the languages. Then he needs to run scripts/entities.php on all the languages of the manual. The unused entities should be deleted (after consulting the mailing list on future used entities). So then we have a list of all entities used in any of the langauges. Then the subset of used entities in the English manual is needed. This will stay in global.ent. All others will move to legacy.ent. Then legacy.ent needs to be wired into manual.xml.in to make it part of the build system. The next step is to write a script to detect the usage of legacy entities in translations, keeping in mind, that currently there can be entities in translations which are not in global.ent and not in legacy.ent as they were removed before the "revolution". So any entity that is not in global.ent should produce an error message. To make the manual build regardless of entity problems, the non-legacy missing entities should be generated much like currently missing-entities.php generates missing entities and IDs. Well, this is the essence of how I think the entity problem can be handled. It includes currently handled problems (missing-entities.php), but as we enhance the system, it will only be a part of them all. Regarding my part in this revolution, I can mainly only provide my ideas now, as I am in a hard university exam time and I need to move further in those areas, as I have not paid enough attention to those things this fall, and I am quite behind the expectations of the teachers... I will be here with decreased power till the end of january, and I will be back in february completely, as my exam period ends. Goba -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
