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.
Great. No opposition yet :)
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.
Well that appendix will have the explanation on misc ini settings, so it will not only be an entity, but a significant part of the contents will be an entity.
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 :)
Now you made me curious on how old are you. :)
- 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.
It is not just the format, but the meaning as well. Literal is not meant to be used for 'product names' AFAIK.
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/
SF does not allow you to host some website which is not closely related to the project you run on SF. We are not going to move the CVS to SF.net, so it is not justifyable to put any services there. It does not fit into the terms of service AFAIK.
Goba