Re: [PHP-DOC] MySQLi extension
Hi Philip, And, should we keep track (document) _when_ extensions became stable? Nice too have, but not really necessary, imho. Regards Friedhelm
Re: [PHP-DOC] MySQLi extension
On 2/11/07, Friedhelm Betz [EMAIL PROTECTED] wrote: Hi Philip, And, should we keep track (document) _when_ extensions became stable? Nice too have, but not really necessary, imho. For PECL, the information is on the PECL website. For php-src, it's maybe worth documenting, but it will clutter the docs, and I'm not sure the info is really useful. Mehdi
Re: [PHP-DOC] MySQLi extension
Hello, Philip Olson wrote: - Original Message - This was already fixed in the English translation, so it's up to the Germans to catch up (-: On that note, Philip just said to me i wonder if we can create a way to store important items across translations, like for example, deprecated status (ex. mysqli from that thread) After a bit of brainstorming, we came up with the idea of creating extension-specific status entities that reference an extension's status, globally (because this sort of thing isn't translation specific). For example, we'd add new global entities: !ENTITY status.pecl.phar warn.experimental; !ENTITY status.ext.mysqli etc. (remember, warn.experimental; is translated) That way, this sort of thing would never happen (once the status.foo; entities make it into the various reference.xml files. bah.. the more the entities, the slower the build becomes. So, let's not interfere with translators work :P Nuno Sure it would add one new entity per extension (that would be used in each translation) so although this is a lot I don't feel the slower build time (wonder how much?) is reason enough to not do it. If we do this, the status of all extensions in every translation will be correct and doing this requires zero additional work for translators. Because most translations are on life support (let's not talk about that now), this feature is even more important. BUT, what else will it lead to? Can we come up with a different/better solution that also takes into account other things, like prototypes? Livedocs? A big +1 on the idea. Who is working on the mega patch? Mehdi
Re: [PHP-DOC] MySQLi extension
This was already fixed in the English translation, so it's up to the Germans to catch up (-: On that note, Philip just said to me i wonder if we can create a way to store important items across translations, like for example, deprecated status (ex. mysqli from that thread) After a bit of brainstorming, we came up with the idea of creating extension-specific status entities that reference an extension's status, globally (because this sort of thing isn't translation specific). For example, we'd add new global entities: !ENTITY status.pecl.phar warn.experimental; !ENTITY status.ext.mysqli etc. (remember, warn.experimental; is translated) That way, this sort of thing would never happen (once the status.foo; entities make it into the various reference.xml files. bah.. the more the entities, the slower the build becomes. So, let's not interfere with translators work :P Nuno Sure it would add one new entity per extension (that would be used in each translation) so although this is a lot I don't feel the slower build time (wonder how much?) is reason enough to not do it. If we do this, the status of all extensions in every translation will be correct and doing this requires zero additional work for translators. Because most translations are on life support (let's not talk about that now), this feature is even more important. BUT, what else will it lead to? Can we come up with a different/better solution that also takes into account other things, like prototypes? Livedocs? A big +1 on the idea. Who is working on the mega patch? I heard Mehdi is but don't know for sure :) And on a related note, what about having a docweb tool scan for EXPERIMENTAL files in php- src, the stable state in PECL (keeping in mind branching), and compare this information to this new status file. Something like that might even help all three locations stay updated. And, should we keep track (document) _when_ extensions became stable? Regards, Philip
Re: [PHP-DOC] MySQLi extension
Hi, Philip Olson wrote: - Original Message - This was already fixed in the English translation, so it's up to the Germans to catch up (-: On that note, Philip just said to me i wonder if we can create a way to store important items across translations, like for example, deprecated status (ex. mysqli from that thread) After a bit of brainstorming, we came up with the idea of creating extension-specific status entities that reference an extension's status, globally (because this sort of thing isn't translation specific). For example, we'd add new global entities: !ENTITY status.pecl.phar warn.experimental; !ENTITY status.ext.mysqli etc. (remember, warn.experimental; is translated) That way, this sort of thing would never happen (once the status.foo; entities make it into the various reference.xml files. bah.. the more the entities, the slower the build becomes. Hey, a computer is a tool to make things magically happen, even for translators ;-) I don't buy this argument without any rough figures. So, let's not interfere with translators work :P Nuno As Sean said: this sort of thing isn't translation specific. Sure it would add one new entity per extension (that would be used in each translation) so although this is a lot I don't feel the slower build time (wonder how much?) is reason enough to not do it. If we do this, the status of all extensions in every translation will be correct and doing this requires zero additional work for translators. Correctness counts more than build time no? Friedhelm
Re: [PHP-DOC] MySQLi extension
Sean Coates wrote: [...] That way, this sort of thing would never happen (once the status.foo; entities make it into the various reference.xml files. Thoughts? Big +1 Friedhelm
Re: [PHP-DOC] MySQLi extension
bah.. the more the entities, the slower the build becomes. So, let's not interfere with translators work :P Nuno - Original Message - This was already fixed in the English translation, so it's up to the Germans to catch up (-: On that note, Philip just said to me i wonder if we can create a way to store important items across translations, like for example, deprecated status (ex. mysqli from that thread) After a bit of brainstorming, we came up with the idea of creating extension-specific status entities that reference an extension's status, globally (because this sort of thing isn't translation specific). For example, we'd add new global entities: !ENTITY status.pecl.phar warn.experimental; !ENTITY status.ext.mysqli etc. (remember, warn.experimental; is translated) That way, this sort of thing would never happen (once the status.foo; entities make it into the various reference.xml files. Thoughts? S
Re: [PHP-DOC] MySQLi extension
- Original Message - This was already fixed in the English translation, so it's up to the Germans to catch up (-: On that note, Philip just said to me i wonder if we can create a way to store important items across translations, like for example, deprecated status (ex. mysqli from that thread) After a bit of brainstorming, we came up with the idea of creating extension-specific status entities that reference an extension's status, globally (because this sort of thing isn't translation specific). For example, we'd add new global entities: !ENTITY status.pecl.phar warn.experimental; !ENTITY status.ext.mysqli etc. (remember, warn.experimental; is translated) That way, this sort of thing would never happen (once the status.foo; entities make it into the various reference.xml files. bah.. the more the entities, the slower the build becomes. So, let's not interfere with translators work :P Nuno Sure it would add one new entity per extension (that would be used in each translation) so although this is a lot I don't feel the slower build time (wonder how much?) is reason enough to not do it. If we do this, the status of all extensions in every translation will be correct and doing this requires zero additional work for translators. Because most translations are on life support (let's not talk about that now), this feature is even more important. BUT, what else will it lead to? Can we come up with a different/better solution that also takes into account other things, like prototypes? Livedocs? Regards, Philip
Re: [PHP-DOC] MySQLi extension
Hi, http://de3.php.net/manual/de/ref.mysqli.php MySQLi isn't experimental to the best of my knowledge. This was probably never removed. This was already fixed in the English translation, so it's up to the Germans to catch up (-: S
RE: [PHP-DOC] MySQLi extension
Ok thanks :) I just saw that someone emailed doc-de@ before me so we should be ok soon (hopefully). Andi -Original Message- From: Sean Coates [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 9:50 PM To: Andi Gutmans Cc: phpdoc@lists.php.net Subject: Re: [PHP-DOC] MySQLi extension Hi, http://de3.php.net/manual/de/ref.mysqli.php MySQLi isn't experimental to the best of my knowledge. This was probably never removed. This was already fixed in the English translation, so it's up to the Germans to catch up (-: S
Re: [PHP-DOC] MySQLi extension
This was already fixed in the English translation, so it's up to the Germans to catch up (-: On that note, Philip just said to me i wonder if we can create a way to store important items across translations, like for example, deprecated status (ex. mysqli from that thread) After a bit of brainstorming, we came up with the idea of creating extension-specific status entities that reference an extension's status, globally (because this sort of thing isn't translation specific). For example, we'd add new global entities: !ENTITY status.pecl.phar warn.experimental; !ENTITY status.ext.mysqli etc. (remember, warn.experimental; is translated) That way, this sort of thing would never happen (once the status.foo; entities make it into the various reference.xml files. Thoughts? S
Re: [PHP-DOC] mysqli extension
I remember the rpl functions have been removed by Georg for some reason. You should contact Georg Richter ([EMAIL PROTECTED]) for more information on the extension. Goba [EMAIL PROTECTED] wrote: I noticed (after commiting files over dead revisions) that some of the replication functions were removed. Should I again remove these files or wait for the information from MySQL about the lib? Kenneth
