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)
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 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.
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.
Great :) It will be cool to discuss the various problems too, like:
- reference skeletons (are we switching to mysqli docs style ?)
I must admit I have not yet checked out what is the style of those docs. I am currently focused on the first part of the manual (installation & configuration). Then I am going to change focus to the language part (need to document the complete oo stuff for PHP 5). That would probably mean that I need to check out what methods can be used to OO docs. (I have put the notes written by Andre L F S Bacci on the topic onto my TODO list)
- 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.
[BTW doc-de and doc-fr also cc-ed, being the two most active translation groups - at least I suspect so]
http://didou.keliglia.com/php/revcheck_php.php5 :)
I always wonder how people can make a translation this up to date... Haaaa..
Goba
