This could have been implemented in any language, of course, but server-side seemed to make a little bit more sense than client-side and PHP is still more or less ubiquitous.
I think there have indeed been small attempts to do this before, as with W3C's P3P [1]. But they always had the (end) user in mind, and tried to build advantages for the user. As we all know, users don't desperately request something like that, and so the big companies who could have pushed this forward had no incentive to do so.
This project, on the other hand, regards benefits for the user only as its long-term "vision", and the important short-term goals are benefits for developers, especially small teams.
By the way, this library requiring PHP should not be much of a hurdle. It uses the most basic and primitive language features only and requires virtually no tooling. A minimal example could be constructed by writing one single file yourself, including all the individual files of the library and then having the respective method calls.
Regarding the general concept, there's a lot of room for improvement, of course, e.g. more translations, support for additional clauses and topics, fixes and enhancements based on input from legal experts, etc.
I would personally prefer to do this client side and then just embed the generated policy. Especially since I use several different languages server-side, often not PHP. Of course I can always run the PHP client-side as well :) Anyway, thanks OP!
Well, the preferences on this subject will probably vary. For me, server-side has been more helpful in practice.
And you really don't have to embed PHP into every project or site that you do. You could build a small internal service that generates the privacy policies in HTML for each project and then include those policies in the individual projects without any additional requirements on the server side.
Maybe time to blow the dust off my PHP binary... Great work!