> >> Sine only the ini_set() page is updated from time to time, this is > >> quite some duplicated stuff, and will no doubt confuse people. What > >> would be ideal IMHO: > >> > >> - move extension relevant stuff to the extension pages > >> (do not have this info on the ini_set() page at all) > >> > >> - move general INI settings explanation and their scope info > >> to an appendix (and do not have this on the ini_set() page)
I agree absolutly with this! I think we should create an appendix with this info and just have a link from ini_set to it. > >> This would leave the introduction on what can be changed where in the > >> introduction part of the manual, while extension specific stuff would > >> be at the extensions, and reference stuff would be in the appendix. > >> That would mean that ini_set() would not have that list of scope info > >> anymore, since that would be distributed to the extension pages and > >> the appendix. We can have an index of all those ini settings in the > >> appendix, if desired. > > > > I'm ok here, but I think that keeping the information about what can be > > changed where in each ini.xml file would be fine too. It's always > > annoying to be obliged to switch between two pages to understand > > something. What about an entity like &ini.changeable.meaning ? (or > > whatever) > > Well, we can replicate the table in multiple places if needed with such > an entity. I agree with an entity here! > I have put some more thought into this yesterday, and uncovered some > other problems. If we go on the 'replace the scope table in the files' > route, which is employed currently, then we need to do this in all > translations as well, to make them up to date. Also these changes make > the revision number of the files go up by one, so if we change the > translations too automatically, then the revision checking will not be > fine with these changes (the file would be be marked out of date, while > it would be up to date). So it might be a good idea to instead of > rewriting the XML files, we would introduce an ini-options.ent file into > the entities folder, which would contain the ini option tables which go > to the different extension sections and which go to the general ini > options section. That way we would only need to update one file with the > INI options generation script (while still with the need of > differentiating between ini options by extensions) and translations > would be automatically up to date. +1 here, too. We could have the appendice file with a simple entity. This would leave all languages always up-to-date. > >> Having the INI stuff sorted out, I will finally be able to propose and > >> actually do the changes needed to make reforms in the installation > >> section, so we can have a better organized section for our users and > >> translators to work with. Now I will have my final tests (so that I can go to the high school next year). I'll end all the tests in the begining of July. Then I'll try to do a script to update the ini settings that could be run automatically. I'm not a regexp expert, but I'm reading the Oreilly's book :) > > - additional entities for a better consistency (&php; for > > <literal>PHP</literal> for example, which will fix [1] > > Why is PHP a literal? It could be a <productname> or something but why a > literal? BTW I am not entirely sure that an entitiy is needed for this. > I would be fine with the style "PHP 4.2.0" without entities. I think that there is no need to have <literal>PHP</literal> as an entity. I think we could use just PHP and get ride of those entities. Just check the migration5.xml appendice in livedocs and wou will see how horrible PHP is formated. Nuno P.S.: I'm in peace :) but what about the website? I was thinking in sourceforge as they allow VHOSTS (and so we could have a docs.php.net). I've mail them to ask if they can update PHP (they have a very old version: 4.2.2) and install the sqlite module, so that we could have livedocs running with all languages. For now, I've set up a cron job that makes a revcheck for all languages (updated everyday): http://phpdocmanager.sourceforge.net/revcheck/
