[PHP-DOC] SVN Account Request: conf
Translating the documentation into the Russian language
Re: [PHP-DOC] Improvements on revcheck.php script
2010/10/12 Philip Olson : > > On Oct 11, 2010, at 1:05 AM, Alexey Shein wrote: > >> Hello! >> I've made some improvements of revcheck.php script and hope you'll >> like them too so they could be taken into the svn: >> 1) fixed E_NOTICE errors >> 2) added console option --show-uptodate, which if supplied will also >> show all up-to-date files in documentation. It can be useful to track >> the translation progress with very obsolete status (as Russian one, >> for example) so after some change translator will see one more green >> (up-to-date) file than one less orange (untranslated) file from other >> same orange 8. >> I tried to keep BC as much as possible, hope there is no errors (at >> least new :)). > > Greetings Alexey, > > Looks good, this patch has been committed. Thanks for improving the PHP > Documentation, and looking forward to seeing more ;) > > Regards, > Philip > > Thanks. -- Regards, Shein Alexey
Re: [PHP-DOC] SVN Account Request: nullw0rm
On Sat, Oct 9, 2010 at 09:16, Alexander Elliott wrote: > My intended purpose is to contribute the current PHP documentation more > complete and error-free by accessing and maintaining user bug reports on a > stable basis that relate. > > Therefor the phpdoc SVN repository I would require access to for this purpose > alone. > We would really appreciate your help! You however do not require SVN access to read or comment on bug reports (be it doc, web, php-src, pear, pecl, ... whatever) . If however you have done so, and noone bogused/closed the report after your (assuming correct) comment.. let me know :) - or Philip - and we'll get you the karma you need. If your comments have included textual descriptions of how to solve the problem; The best way to gain SVN access is to contribute couple of patches - just to showcase that you actually do know what you are doing :) People submitting patches tend to get karma quite quickly :) -Hannes
Re: [PHP-DOC] License for code examples in the PHP manual?
On Mon, Oct 11, 2010 at 18:04, Hannes Magnusson wrote: > > "The PHP Documentation Group" is not explicitly defined anywhere, so > does that mean this mailinglist? The named authors on > http://php.net/manual? (and does that include the 'and several > others'?) :P Could the "PHP Documentation Group" be a list that's updated each year - perhaps dynamically - by tallying the activities of users and taking, say, the top ten or twenty from the previous calendar year? That would ensure that it's always a fresh list, instead of becoming as stale as some other statically-defined groups, and that answers definitively, once and for all, of whom this clandestine crew is comprised. ;-P -- Network Infrastructure Manager Documentation, Webmaster Teams http://www.php.net/
Re: [PHP-DOC] License for code examples in the PHP manual?
On Mon, Oct 11, 2010 at 22:34, Robinson Tryon wrote: > On Mon, Oct 11, 2010 at 4:07 PM, Philip Olson wrote: >> >> I avoid the topic of licenses whenever possible but let's make a decision. >> It feels like most would prefer dual licensing for code snippets (despite >> GPL and PHP not getting along all that well, ever) so let's do that. > > Okay. > >> Does someone here have a lawyer friend who will look over the proposed >> change? >> >> Regards, >> Philip > > Sure, I'm happy to take point on that. I'll pass along the information > from this thread and let the list know as soon as I hear something > back from the lawyers. Woha. That would be awesome :D While you are at it; Who exactly is allowed to make this change? (And where/in which files?) "The PHP Documentation Group" is not explicitly defined anywhere, so does that mean this mailinglist? The named authors on http://php.net/manual? (and does that include the 'and several others'?) :P I personally have done 2 legal fixes (or breakages?) to the docs so far.. Unsure if I'm willing to "risk" the 3rd one :) -Hannes
Re: [PHP-DOC] License for code examples in the PHP manual?
On Mon, Oct 11, 2010 at 4:07 PM, Philip Olson wrote: > > I avoid the topic of licenses whenever possible but let's make a decision. It > feels like most would prefer dual licensing for code snippets (despite GPL > and PHP not getting along all that well, ever) so let's do that. Okay. > Does someone here have a lawyer friend who will look over the proposed change? > > Regards, > Philip Sure, I'm happy to take point on that. I'll pass along the information from this thread and let the list know as soon as I hear something back from the lawyers. Thanks, -- Robinson
Re: [PHP-DOC] License for code examples in the PHP manual?
On Oct 4, 2010, at 12:41 PM, Robinson Tryon wrote: > On Mon, Oct 4, 2010 at 3:03 PM, Daniel Brown wrote: >>I'm of the opinion that we should license all >> machine-interpretable examples (i.e. - "code snippets") in both the >> official documentation usage examples and user-submitted examples >> alike - including those from the mailing lists and archives - under >> either the MIT or New BSD license, so it was good to see someone else >> mention those two explicitly. A simple ratification to the license >> information pages would suffice. Exempli gratia: >> >>"The PHP manual text and user-submitted comments are released >> under the Creative Commons Attribution 3.0 License, Copyright (C) the >> PHP Documentation Group, with the exception of machine code regions >> (AKA - "code snippets") in the documentation or freely submitted by >> the public, which is licensed under [MIT/NBSD]." > > As suggested in the DFSG FAQ, I think that a dual-licensing scheme > would provide the most clarity and flexibility for the code embedded > in the documentation. (I'd also suggest putting the copyright notice > before the license name, otherwise it's unclear whether it is the > manual or the CC license that is copyright by the PHP Doc Group!) > > To riff off of your example: > > "The PHP manual is Copyright (C) the PHP Documentation Group, and is > released under the Creative Commons Attribution 3.0 License. The > machine code regions (AKA - "code snippets") in the documentation or > freely submitted by the public, are also licensed under the > [MIT/NBSD]." > > I'm sure that there's a good way to tighten up the language about the > "example code"/"code snippets" a bit. I'm sure we could find a lawyer > or two to review the text, if it would be helpful. I avoid the topic of licenses whenever possible but let's make a decision. It feels like most would prefer dual licensing for code snippets (despite GPL and PHP not getting along all that well, ever) so let's do that. Does someone here have a lawyer friend who will look over the proposed change? Regards, Philip
Re: [PHP-DOC] Making PHP 5 a first class citizen
On Oct 11, 2010, at 12:20 PM, Julien Pauli wrote: > My example was http://www.php.net/manual/en/language.variables.predefined.php > > I have other examples of what I globally mean, these kinds are recurrent : > > - "Note: The null type was introduced in PHP 4." > - "Warning : Before PHP 4.3.0, appending to an array in which the > current maximum key was negative would create a new key as described > above. Since PHP 4.3.0, the new key will be 0." > - The whole chapter # Object Aggregation — Object > Aggregation/Composition [PHP 4] > - http://www.php.net/manual/en/session.configuration.php has lots of > PHP4 history like "session.gc_divisor ; Available since PHP 4.3.2." > - "PHP supports CLI SAPI since PHP 4.3.0" > - "Note : In PHP 4.0.3 and older, in order to use URL wrappers, you > were required to configure PHP using the configure option > --enable-url-fopen-wrapper ." > - "Note : The Windows versions of PHP earlier than PHP 4.3 did not > support remote file accessing for the following functions : XYZ" > - "Note : Heredoc was added in PHP4" > > etc... > > What I mean is that, yes we should keep an history because its > interesting to know what things happen, and when. But that history > *should be kept in a specific part of the doc*, and *not* in the > actual reference manual (regarding PHP4 at least) > > 99% of users visiting function or language specific pages of the > manual dont care about the NULL type having spawned in PHP4, or that > PHP supports CLI since 4.3.0. They are just looking for some info for > their code and they are often disturbed while grabbing info by some > "PHP4.X.Y things that are not here anymore in PHP4.XX.YY but back in > PHP5" so yes, we are in PHP5, why that sentence ?. > > We should keep an history, but in a specific chapter. People today > dont write code under PHP4, they *at least* maintain PHP4 apps alive, > but dont work on PHP4 code anymore. > > Now about PHP5, it could be the same for 5.0 or even 5.1. We should > have a debate about that as we can still see some PHP5.1 (RedHat) > apps, but talking about PHP4 : it just keeps the reading heavy and > sometimes even boring. There are two overlapping routes we can take here (and I'm sure others too): (A) Remove [most] all references to PHP 4. - This means we remove all the examples you showed because PHP 4 falls into the category of PHP 3. It's just PHP. In other words, PHP always had NULL, and foreach() always existed. (B) Make PHP 5 a first class citizen. - This means we talk about PHP 5 as PHP, so never have "As of PHP 5" because PHP 5 is the present. This however still means we keep track of PHP 4. Although I used to lean towards (B), I think it's time we go with (A). This means all PHP 4 history is moved to a single location, with PHP 3 being an example: - http://php.net/manual/php3.php One concern is comparing the PHP 4 version with the current 4->5 migration guide. We don't want to lose anything, and because the migration guide doesn't cover PHP 4.x.x specific changes there will be two documents: (1) The 4->5 migration guide and (2) PHP 4 version specific changes. Does this sound reasonable? Regards, Philip
Re: [PHP-DOC] Making PHP 5 a first class citizen
My example was http://www.php.net/manual/en/language.variables.predefined.php I have other examples of what I globally mean, these kinds are recurrent : - "Note: The null type was introduced in PHP 4." - "Warning : Before PHP 4.3.0, appending to an array in which the current maximum key was negative would create a new key as described above. Since PHP 4.3.0, the new key will be 0." - The whole chapter # Object Aggregation — Object Aggregation/Composition [PHP 4] - http://www.php.net/manual/en/session.configuration.php has lots of PHP4 history like "session.gc_divisor ; Available since PHP 4.3.2." - "PHP supports CLI SAPI since PHP 4.3.0" - "Note : In PHP 4.0.3 and older, in order to use URL wrappers, you were required to configure PHP using the configure option --enable-url-fopen-wrapper ." - "Note : The Windows versions of PHP earlier than PHP 4.3 did not support remote file accessing for the following functions : XYZ" - "Note : Heredoc was added in PHP4" etc... What I mean is that, yes we should keep an history because its interesting to know what things happen, and when. But that history *should be kept in a specific part of the doc*, and *not* in the actual reference manual (regarding PHP4 at least) 99% of users visiting function or language specific pages of the manual dont care about the NULL type having spawned in PHP4, or that PHP supports CLI since 4.3.0. They are just looking for some info for their code and they are often disturbed while grabbing info by some "PHP4.X.Y things that are not here anymore in PHP4.XX.YY but back in PHP5" so yes, we are in PHP5, why that sentence ?. We should keep an history, but in a specific chapter. People today dont write code under PHP4, they *at least* maintain PHP4 apps alive, but dont work on PHP4 code anymore. Now about PHP5, it could be the same for 5.0 or even 5.1. We should have a debate about that as we can still see some PHP5.1 (RedHat) apps, but talking about PHP4 : it just keeps the reading heavy and sometimes even boring. Regards, J.Pauli On Mon, Oct 11, 2010 at 8:22 PM, Philip Olson wrote: > > On Oct 11, 2010, at 1:38 AM, Julien Pauli wrote: > > > Ok, so we put away all PHP4 terms from docs which mix PHP4 ans PHP5 ? > > Not sure what you mean. If decided, we'll remove them. Maybe you have an > example or three? > > > What to do for docs like "Predifined Variables" which highly rely on PHP 4 > > (register globals switch) ? > > I'm not sure what you mean here, and don't see the problem. In other words, I > don't see how this relates to PHP 4. > > Regards, > Philip
Re: [PHP-DOC] Improvements on revcheck.php script
On Oct 11, 2010, at 1:05 AM, Alexey Shein wrote: > Hello! > I've made some improvements of revcheck.php script and hope you'll > like them too so they could be taken into the svn: > 1) fixed E_NOTICE errors > 2) added console option --show-uptodate, which if supplied will also > show all up-to-date files in documentation. It can be useful to track > the translation progress with very obsolete status (as Russian one, > for example) so after some change translator will see one more green > (up-to-date) file than one less orange (untranslated) file from other > same orange 8. > I tried to keep BC as much as possible, hope there is no errors (at > least new :)). Greetings Alexey, Looks good, this patch has been committed. Thanks for improving the PHP Documentation, and looking forward to seeing more ;) Regards, Philip
Re: [PHP-DOC] Making PHP 5 a first class citizen
On Oct 11, 2010, at 1:38 AM, Julien Pauli wrote: > Ok, so we put away all PHP4 terms from docs which mix PHP4 ans PHP5 ? Not sure what you mean. If decided, we'll remove them. Maybe you have an example or three? > What to do for docs like "Predifined Variables" which highly rely on PHP 4 > (register globals switch) ? I'm not sure what you mean here, and don't see the problem. In other words, I don't see how this relates to PHP 4. Regards, Philip
Re: [PHP-DOC] Making PHP 5 a first class citizen
On Oct 11, 2010, at 3:51 AM, Richard Quadling wrote: > On 23 January 2010 07:25, Philip Olson wrote: >> Hello everyone, >> >> What do people think about making PHP 5 a first class citizen? If done, we'd >> no longer have phrases like: >> >> - As of PHP 5 >> - Since PHP 5 >> - Added in PHP 5 >> >> Because readers are expected to be using PHP 5. However, I'm against version >> (x.X.x) specific manuals for two main reasons: >> >> - It's a lot of work to maintain >> - Knowledge is power, and many write applications to work on a wide array >> of minor PHP versions >> >> And because nobody really uses 5.0.x, we could easily make 5.1.0 the base. >> And we could tag the current manual and have it available somewhere, in case >> some pour soul really wants it. What do people think? > > > I've just read through this thread. My one concern is to find a > mechanism which is easy to implement for future versions/releases. > > One day Unicode will be part of PHP and may even become the standard > way, with b'strings' becoming a thing of the past, just like PHP4, and > u'Strings' becoming just 'Strings'. But Unicode will not be adopted > overnight. No more than PHP5 was over PHP4. All those string functions > will certainly need to be very clear about the difference between > unicode and non-unicode string handling. And the differences between > PHP4 and PHP5 have been well documented (by version tags, or inline > "since PHPxyx" text). We have a 'unicode' role for this reason, which was going to be used but then the PHP 6 fiasco happened. It's still available though. However, nobody is talking about unicode anymore so I'm not holding my breath despite it being where the web is going (or has gone). > For a user coming to PHP for the first time (hopefully this will > always happen), having a manual for THEIR version (whatever it may be) > is probably what they would want. Having documentation about dead or > unusable features ... sometimes it may be in the way and sometimes it > may give impetus to upgrade. I think it's important for users to be aware of why their code may not work in previous or future versions of PHP. I agree it can get in the way, but think it's worth it (especially if done right). > The changelog section for functions is great. Having a changelog for > non-function usage would be great too, but I think we would need just > as many references telling a user who is NOT on the most recent > version that the documentation they are reading is not right for them > and to look in another section. PHP is a BC friendly language and rarely has drastic changes. I don't think this concern is a big problem. > For significant changes, having headings for each version would seem > to be an appropriate way to handle things (for non functions / > changelogs). I'd probably suggest only 2 or 3 versions with the > remaining versions grouped into a single page or hived off to an > archive section when no longer relevant. I'm looking at how Apache and > IIS are documented within PHP - 1 page for each significant version > (Apache 1.3x, 2.x, IIS 5.1 and 6, IIS 7+) Not sure how that would work but it's a rare condition. New features like traits and garbage collection are version specific but over time they won't be. I can't think of any major changes to features except for OOP, and do think we could have handled that better. Syntax changes like if $arr[1,4] exists, or annotations, or foo()[4], those could get tricky. But I'm sure your idea of headings/pages for some features will be useful. > An idea which I'm pretty sure has been mentioned before in this list > is to be able to tag chunks/elements in the XML in such a way that > when you are editing a page, you see all the history in 1 go. But when > the manual is built, the older sections are rendered into an archive > section. No need to actually move anything around. XML attributes are one idea but what it'd generate/do hasn't been investigated. And as someone who thinks knowing the future/past is important, I don't see real value in hiding/moving content based on it. The main use is to have it organized so it'd be easier to deal with both now and well into the future. Regards, Philip
Re: [PHP-DOC] Making PHP 5 a first class citizen
On 23 January 2010 07:25, Philip Olson wrote: > Hello everyone, > > What do people think about making PHP 5 a first class citizen? If done, we'd > no longer have phrases like: > > - As of PHP 5 > - Since PHP 5 > - Added in PHP 5 > > Because readers are expected to be using PHP 5. However, I'm against version > (x.X.x) specific manuals for two main reasons: > > - It's a lot of work to maintain > - Knowledge is power, and many write applications to work on a wide array of > minor PHP versions > > And because nobody really uses 5.0.x, we could easily make 5.1.0 the base. > And we could tag the current manual and have it available somewhere, in case > some pour soul really wants it. What do people think? I've just read through this thread. My one concern is to find a mechanism which is easy to implement for future versions/releases. One day Unicode will be part of PHP and may even become the standard way, with b'strings' becoming a thing of the past, just like PHP4, and u'Strings' becoming just 'Strings'. But Unicode will not be adopted overnight. No more than PHP5 was over PHP4. All those string functions will certainly need to be very clear about the difference between unicode and non-unicode string handling. And the differences between PHP4 and PHP5 have been well documented (by version tags, or inline "since PHPxyx" text). For a user coming to PHP for the first time (hopefully this will always happen), having a manual for THEIR version (whatever it may be) is probably what they would want. Having documentation about dead or unusable features ... sometimes it may be in the way and sometimes it may give impetus to upgrade. The changelog section for functions is great. Having a changelog for non-function usage would be great too, but I think we would need just as many references telling a user who is NOT on the most recent version that the documentation they are reading is not right for them and to look in another section. For significant changes, having headings for each version would seem to be an appropriate way to handle things (for non functions / changelogs). I'd probably suggest only 2 or 3 versions with the remaining versions grouped into a single page or hived off to an archive section when no longer relevant. I'm looking at how Apache and IIS are documented within PHP - 1 page for each significant version (Apache 1.3x, 2.x, IIS 5.1 and 6, IIS 7+) An idea which I'm pretty sure has been mentioned before in this list is to be able to tag chunks/elements in the XML in such a way that when you are editing a page, you see all the history in 1 go. But when the manual is built, the older sections are rendered into an archive section. No need to actually move anything around. Regards, Richard Quadling. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
Re: [PHP-DOC] Making PHP 5 a first class citizen
Ok, so we put away all PHP4 terms from docs which mix PHP4 ans PHP5 ? What to do for docs like "Predifined Variables" which highly rely on PHP 4 (register globals switch) ? J.Pauli On Sat, Oct 9, 2010 at 6:37 PM, Philip Olson wrote: > > On Oct 8, 2010, at 10:30 AM, Julien Pauli wrote: > > > I'm just putting back the subject here ;-) > > > > Actually translating French doc, I noticed that few days ago, a change to > the original (en) source from PCRE had a huge diff deleting all the > "available since PHP4.X.Y". Same inside other sources from En doc. > > > > So, what to do ? > > > > I'm +1 to put away all the references with "PHP4" inside. We all know > PHP4 is not supported any more, it should just move to the museum. > > Actually, I'm reading and correcting typos in the Fr doc, should I go to > remove everything talking about PHP4 (obviously except the specific chapter > about PHP4 objects) ? > > > > Exemple from session : "PHP_INI_ALL in PHP <= 4.2.3. PHP_INI_PERDIR in > PHP < 5. Available since PHP 4.0.3" > > That is something really boring to read, confusing, and completly out of > date. > > Greetings Julien, > > Okay, let's do it. Creating changelog entries everywhere is one option but > the work involved no longer feels worth it. Let's consider the current > manual as "The PHP 4/5 Manual" and finally remove all PHP 4 specific > references from SVN. Well, except for a few exceptions like the dom page > should mention the domxml vs dom issue. > > The topic of version specific manuals comes up occasionally but I don't see > it working. I won't go into detail with my feelings now, but lean towards > thinking it's a bad idea even if it could be done with a magic wand. > > As for which version of PHP 5 to go with, that's a tougher question. I > forget most of the proposed solutions but think there are several and will > search the archives this week. Solutions that limit the inline versioning > text (e.g., "As of PHP 5.1.0, Foo and Bar...") are ideal. I think version > specific XML attributes was one thought, where PhD would handle it and > output something useful. > > And lastly, the INI version information is/was generated by > doc-base/scripts/iniupdate/* but in reality, it no longer works and people > have been editing the XML by hand. However, it's something to keep in mind. > > What do people think about all of this? :) > > Regards, > Philip > >
[PHP-DOC] Improvements on revcheck.php script
Hello!
I've made some improvements of revcheck.php script and hope you'll
like them too so they could be taken into the svn:
1) fixed E_NOTICE errors
2) added console option --show-uptodate, which if supplied will also
show all up-to-date files in documentation. It can be useful to track
the translation progress with very obsolete status (as Russian one,
for example) so after some change translator will see one more green
(up-to-date) file than one less orange (untranslated) file from other
same orange 8.
I tried to keep BC as much as possible, hope there is no errors (at
least new :)).
--
Regards,
Shein Alexey
Index: doc-base/scripts/revcheck.php
===
--- doc-base/scripts/revcheck.php (revision 293138)
+++ doc-base/scripts/revcheck.php (revision )
@@ -22,14 +22,14 @@
$Id: revcheck.php 293138 2010-01-05 10:21:11Z rquadling $
*/
-if ($argc < 2 || $argc > 3) {
+if ($argc < 2 || $argc > 4) {
?>
Check the revision of translated files against
the actual english xml files, and print statistics
Usage:
-[]
+[] [--show-uptodate]
must be a valid language code used
in the repository
@@ -37,6 +37,9 @@
If you specify , the script only checks
the files maintained by the person you add here
+ If you specify --show-uptodate option, the script will
+ also show uptodate files in the common file list
+
Read more about Revision comments and related
functionality in the PHP Documentation Howto:
http://php.net/dochowto
@@ -76,17 +79,40 @@
REV_WIP => "wip",
);
+function init_revisions() {
+ global $CSS;
+ return array_fill_keys(array_keys($CSS), 0);
+}
+
+function init_files_by_maint($persons) {
+ $result = array();
+ foreach($persons as $item) {
+$result[$item['nick']] = init_revisions();
+ }
+
+ return $result;
+}
+
+$file_sizes_by_mark = $files_by_mark = init_revisions();
+
// Option for the link to svn.php.net:
define('SVN_OPT', '&view=patch');
define('SVN_OPT_NOWS', '');
// Initializing variables from parameters
$LANG = $argv[1];
+$MAINT = "";
+$SHOW_UPTODATE = FALSE;
if ($argc == 3) {
-$MAINT = $argv[2];
+ if ($argv[2] == '--show-uptodate') {
+ $SHOW_UPTODATE = TRUE;
-} else {
+} else {
-$MAINT = "";
+ $MAINT = $argv[2];
-}
+ }
+} elseif ($argc == 4) {
+$MAINT = $argv[2];
+$SHOW_UPTODATE = ($argv[3] == '--show-uptodate');
+}
// Main directory of the PHP documentation (depends on the
// sapi used). We do need the trailing slash!
@@ -172,7 +198,7 @@
function get_file_status($file) {
// The information is contained in these global arrays and vars
- global $DOCDIR, $LANG, $MAINT, $files_by_mark, $files_by_maint;
+ global $DOCDIR, $LANG, $MAINT, $SHOW_UPTODATE, $files_by_mark, $files_by_maint;
global $file_sizes_by_mark;
global $missing_files, $missing_tags, $using_rev;
@@ -246,23 +272,17 @@
$en_rev = $en_rev;
}
- // If the file is up-to-date
- if ($rev_diff === 0 && trim($this_status) === "ready") {
-// Store file by status and maintainer
-$files_by_mark[REV_UPTODATE]++;
-$files_by_maint[$this_maint][REV_UPTODATE]++;
-$file_sizes_by_mark[REV_UPTODATE] += $en_size;
-
-return FALSE;
- }
-
// Compute times and diffs
$en_date= intval((time() - filemtime($file)) / 86400);
$trans_date = intval((time() - filemtime($trans_file)) / 86400);
$date_diff = $en_date - $trans_date;
- // Make decision on file category by revision, date and size
- if ($rev_diff >= ALERT_REV || $size_diff >= ALERT_SIZE || $date_diff <= ALERT_DATE) {
+ // If the file is up-to-date
+ if ($rev_diff === 0 && trim($this_status) === "ready") {
+ $status_mark = REV_UPTODATE;
+ }
+ // Or make decision on file category by revision, date and size
+ elseif ($rev_diff >= ALERT_REV || $size_diff >= ALERT_SIZE || $date_diff <= ALERT_DATE) {
$status_mark = REV_CRITICAL;
} elseif ($rev_diff === "n/a") {
$status_mark = REV_NOREV;
@@ -277,6 +297,10 @@
$files_by_maint[$this_maint][$status_mark]++;
$file_sizes_by_mark[$status_mark] += $en_size;
+ if (REV_UPTODATE === $status_mark && !$SHOW_UPTODATE) {
+return FALSE;
+ }
+
return array(
"full_name" => $file,
"short_name" => basename($trans_file),
@@ -579,6 +603,7 @@
// Add WIP files to maintainers file count and figure out,
// if we need to use optional date and revision columns
$using_date = FALSE; $using_rev = FALSE;
+$files_by_maint = init_files_by_maint($translation['persons']);
foreach ($translation["files"] as $num => $fileinfo) {
$files_by_maint[$fileinfo["person"]][REV_WIP]++;
if (isset($fileinfo["date"])) { $using_date = TRUE; }
