Re: [PHP-DOC] Anonymous functions is equal to lambda not closure
2010-02-23 13:44, Hannes Magnusson skrev:
On Tue, Feb 23, 2010 at 13:07, Keryx Webwebmas...@keryx.se wrote:
Re this page:
http://php.net/manual/en/functions.anonymous.php
Closures (as described on that page) in PHP are actually closures.
We already have lambda functions..
Unless scope is inherited a function (anonymous or not) is not a closure.
Lambda does not return anything (of value) when I search the manual.
Are you refering to create_function()?
That is just another, older and more awkward, way of doing lambda.
Back to the page we are discussing:
This code example...
?php
echo preg_replace_callback('~-([a-z])~', function ($match) {
return strtoupper($match[1]);
}, 'hello-world');
// outputs helloWorld
?
...has no closure in sight at all. Just an anonymous function. Lambda.
It is not until example 3 that we have a closure.
Anyway, using closure as a *synonym* to anonymous function is not
correct from a computer science perspective and it is confusing for
anyone using both PHP and JavaScript - and who isn't these days?
I think the better way to simply rename the chapter from 'anonymous
functions' to 'closures' - but then we risk people that dont know what
a closure is will never click it.
A *lot* of people that use PHP have no idea what 'closure' is, but a
'anonymous function' sounds interesting to them, hence getting them to
click it and discover closures.
It is especially the newbies I am worried about - it is after all my day
job to train them. I do not mind them discovering closures, it is just
that they should not be confused about what a closure really is.
--
Keryx Web (Lars Gunther)
http://keryx.se/
http://twitter.com/itpastorn/
http://itpastorn.blogspot.com/
[PHP-DOC] Anonymous functions is equal to lambda not closure
Hello Re this page: http://php.net/manual/en/functions.anonymous.php Outside the world of PHP nobody seem to be using the word closure as if it was a synonym to anonymous function. I will provide some examples: blockquote cite=https://developer.mozilla.org/en/Core_JavaScript_1.5_Guide/Working_with_Closures; ...MyFunc has BECOME a closure. A closure is a special kind of object that combines two things: a function, and the environment in which that function was created. /blockquote blockquote cite=http://www.javascriptkit.com/javatutors/closures.shtml; Two one sentence summaries: * a closure is the local variables for a function - kept alive after the function has returned, or * a closure is a stack-frame which is not deallocated when the function returns. (as if a 'stack-frame' were malloc'ed instead of being on the stack!) blockquote blockquote cite=http://www.webreference.com/programming/javascript/rg36/; A closure takes place when a function creates an environment that binds local variables to it in such a way that they are kept alive after the function has returned. A closure is a special kind of object that combines two things: a function, and any local variables that were in-scope at the time that the closure was created. /blockquote (Re 2nd sentence: I don't know if this is the original or if MDC is.) See also JavaScript, The Definitive Guide, by David Flanagan, (5th ed) section 8.8.4 on page 143f: This combination of code and scope is known as a closure in the computer science literature (p.144 - the word this refers to inner functions keeping outer functions data even after return as discussed previously by DF.) It has been my job for a few years to evaluate books on JavaScript and I have read more than 10 published between 2005 and 2009. They are very consistent in their usage of the word closure. To top things off, it seems that I am in agreement with the editors on Wikipedia: blockquote cite=http://en.wikipedia.org/wiki/Closure_%28computer_science%29; The term closure is often mistakenly used to mean anonymous function. This is probably because most languages implementing anonymous functions allow them to form closures and programmers are usually introduced to both concepts at the same time. These are, however, distinct concepts. /blockquote Computer science savvy people, like Douglas Crockford, tend to call anonymous functions lambda. Sometimes (C# et al) they are called lambda expressions. However, lambda might not be a 100 % fit either from a computer science perspective, but it sure is a lot better fit than closure. I think that the PHP community perhaps calls anonymous functions closures because it is one word less to say and type, and we might need a single word term to use. Therefore I'd suggest a rewrite of the manual page. First paragraph, suggested text: Anonymous functions, also known as lambda, allow the creation of functions which have no specified name. They are most useful as the value of callback parameters, but they have many other uses. Second paragraph introduces a problem, since it would references a misnamed internal class. I'd suggest that is made anonymous! Anonymous functions can also be used as the values of variables; PHP automatically converts such expressions into instances of the corresponding internal class. Assigning an anonymous function to a variable uses the same syntax as any other assignment, including the trailing semicolon: Third paragraph, suggested text: Lambda functions may also inherit variables from the parent scope, in which case they are called closures. Fourth paragraph cannot be changed of course, until the internal Closure class has been appropriately renamed. -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/
Re: [PHP-DOC] A small suggestion to the CSS
Hannes Magnusson skrev:
On Thu, Jan 8, 2009 at 09:03, Nilgün Belma Bugüner
r,
Index: xhtml.php
===
RCS file: /repository/phd/formats/xhtml.php,v
retrieving revision 1.84
diff -u -r1.84 xhtml.php
--- xhtml.php 3 Jan 2009 12:55:22 - 1.84
+++ xhtml.php 8 Jan 2009 07:58:11 -
@@ -802,11 +802,11 @@
public function format_methodparam_parameter($open, $name, $attrs) {
if ($open) {
if (isset($attrs[PhDReader::XMLNS_DOCBOOK][role])) {
-return ' tt class=parameter referenceamp;$';
+return ' itt class=parameter referenceamp;$';
}
-return ' tt class=parameter$';
+return ' itt class=parameter$';
}
-return /tt;
+return /tt/i;
Lars would slap you with his semantic wand if this gets committed.
The CSS changes earlier in this thread are fine with me if someone
wants to commit.
-Hannes
Indeed. That i-element serves only a presentational cause and therefore
should be handled by CSS.
A good rule of thumb when it comes to (X)HTML is to be very reluctant
about adding tags or attributes, and very eager to strip them out.
Lars Gunther
Re: [PHP-DOC] A small suggestion to the CSS
Kalle Sommer Nielsen skrev: font-family: Consolas, Monaco, Courier New, Courier, monospace; This just came in on Sitepoint: http://www.sitepoint.com/article/eight-definitive-font-stacks/ Page 2 has the monospace stack: http://www.sitepoint.com/article/eight-definitive-font-stacks/2 It may be a bot over the top, so this is my suggestion for a commit: font-family: Consolas, Andale Mono WT, Andale Mono, Lucida Console, Monaco, Courier New, Courier, monospace; Lars Gunther
Re: [PHP-DOC] Proper markup is not a burden. Was XHTML.
Hannes Magnusson skrev: (a) using the target attribute to open links (also in user notes) in a new window, which requires the frameset DTD. This should really be avoided. Most users find such behavior annoying. I find it really annoying clicking on links that don't open another domain in new tabs. There is nothing more natural then to add target to links leading away from the current site. Common courtesy if you ask me. I am relying on research done by Jacob Nielsen and other gurus in the usability and accessibility crowd. http://www.useit.com/alertbox/990530.html (c) input type=image src=http://static.php.net/www.php.net/images/small_submit.gif; id=changeLangImage alt= / Missing alt-text. Should be something like change language (i.e. describing function, not looks.) This is *not* a decorative image. Fine. Fixed. Firefox doesn't display the value though. Correct. Neither will Opera, Chrome, Safari or any other decent browser. Alt text is not supposed to be displayed as a tooltip, since it is intended to be shown (or spoken or felt through braille, etc) for users that do not see the image. MSIE got this wrong and it has been killing accessibility on the web ever since. MSIE is cleaning up their act, though. (Want a tooltip? Use the title attribute! Want to shut down the tooltip in MSIE? img alt=foo title=) (d) Notes are marked up as blockquotes. They are not quotes. Ouh? The user said these things, why is that not a quote? I was not referring to user submitted notes, but to the inline notes in the boxes of the actual manual. E.g: http://se.php.net/manual/en/intl.examples.basic.php (e) Headings in the notes are marked up with the b-element, when they really should be headings. This is bed and breakfast markup. b + br where a heading is the right element fir the job. You mean the smallUser Contributed Notes/smallstrongpage-name/strong? Once again I was referring to the notes in the actual manual, but it will apply to user notes as well. Minor gripes: (a) Anorectic anchors: a name=87685/a div class=note Should be shortened to: div id=87685 class=note Browser don't support it. They don't even support a name=... /... and IDs cannot be integers, but names can :) Stupid me, not noting that the ids were integers! div id=_87685 class=note Is however legal and will work in all browsers. Is that an option? (b) The strong element is used to produce bold text, even though no emphasis is intended. When the heading is repeated above the user contributed notes it should be marked up as a heading. Not using strong. Users that contribute notes should not be put in bold using strong either. In fact HTML 5 *recommends* using the b element for exactly such usage: http://www.whatwg.org/specs/web-apps/current-work/#the-cite-element Confusing. This back and forth is annoying. Make up your mind people. There was a time back in 2003/4 when people started to discover standards in a big way, when developers like me stopped using b and i since they were unsemantic, and instead used strong and em, even though we still only intended to get a bold or italic effect. Or perhaps we used this monstrosity span style=font-weight: boldword/span since the span element was unsemantic by nature. There even exist quite a lot of posts on the internet saying that b and i were deprecated in HTML 4.01 transitional and dropped in 4.01 strict. Or even more confusingly that they are allowed in HTML but disallowed in XHTML, even though XHTNML 1.0 and HTML 4.01 share exactly the same vocabularies! The pendulum simply swung to far. HTML 5 WG and WHATWG have discussed b and i and the large majority agrees that they have a valid use, indicating alternate voice or mood, since that really is what people generally are intending - when they are not abusing the elements to create headers... Anyway, strong is really emphasized. Screen readers will almost shout. em is normal emphasis, and screen readers will speak a bit louder than usual. Braille terminals might provide emphasis through tactile means. using strong and em when no emphasis is intended will really hurt accessibility. (d) Redundant classes? em class=emphasis When is em not used to denote emphasis? This is application generated markup. It *must* to be possible to distinguish docs/generated markup to regular markup. Would it not be easier to put that once and for all on the containg element? E.g. div class=generated I'll add one more place where markup can be reduced. On pages such as http://se.php.net/manual/en/array.constants.php we have a redundant span-elements in the dt and perhaps also the dl elements. Why not apply the class directly to dt and dd? Lars Gunther
[PHP-DOC] A small suggestion to the CSS
As the title says:
Line 12-14:
code, pre, tt {
font-family: Consolas, Courier New, Courier, monospace;
}
Added Consolas, which will benefit anyone using Vista, Offive 2007 or
have downloaded the fonts, perhaps through the ppt-viewer.
Consolas really is a superb monospace font ad it is becoming ubiquitous.
Courier New is one of the ugliest in existence.
A nice font for Linux might be DejaVu Sans Mono, but other are perhaps
more qualified to recommend one.
Lars Gunther
Re: [PHP-DOC] Proper markup is not a burden. Was XHTML.
Hannes Magnusson skrev: Long long long long post, which I haven't read fully yet. Just wanted to clarify few things you seem to have misunderstood. In order not to burden this list with irrelevant stuff, I've discussed a few things with Hannes in private emails. There was some confusion, mainly coming from different usage of terms. *Strict* When I talk about being strict, I refer to using a strict DTD in the Doctype, i.e. HTML 4.01 strict or XHTML 1 strict. We agree that there is no speed penalty in browsers for being strict. *True* When I talk about XHTML sent with an XML MIME header, usually application/xhtml+xml, I call that true XHTML. We agree that Firefox before version 3.0 did not render true XHTML incrementally, and that MSIE = 8.0 and most probably 9.0 won't handle it at all. We agree that true XHTML is unusable PhD, now and for all foreseeable future. So what flavor should PhD use? (My personal opinion follows.) Currently it uses XHTML 1.0 transitional according to its DTD, sent out as text/html, in accordance with the infamous appendix C of the XHTML spec, that allows it - as a transitional measure. I recommend HTML 5 - using that subset of elements and attributes that is supported by todays browsers. To start with only one single change is needed. Shortening the Doctype to: !DOCTYPE html Google is already doing this on some of their pages. I am doing it for all my new projects. It will trigger standards mode in all current and future browsers. It will also put MSIE 8+ in super standards mode, and not the awful MSIE 7 compatibility mode. To check whether the markup is acceptable, one does not look for *valid* code according to the DTD, but for *conformant* code, according to a conformance checker. Being HTML 5 conformant should be a long term goal. It is not an immediate need. IMHO. Lars Gunther
Re: [PHP-DOC] Proper markup is not a burden. Was XHTML.
Politics at the top. Useful criticism at the bottom... Hannes Magnusson skrev: Right. As I see HTML5 it is simply a how to deal with errors appendix for browser vendors. A point that I tried to correct. It is much, much more than that. It includes new elements and attributes, it deprecates all presentational markup still left in (X)HTML with the strict flavor (good bye rows and cols on textarea - finally!), it provides API:s and DOM bindings, etc. PHP's documentation should perhaps not move to HTML 5 (yet). But not for that reason. There is no such concept as valid web page implemented on the web today. validator.w3.org doesn't send out correct headers and neither search.yahoo.com or google.com validate. a. Yes there is. E.g. Google makes a plethora of services besides its main search page, where validation is part of the development process. In fact, Ian Hickson, editor of the HTML 5 spec, works for Google! b. Most invalidness comes from CMS-vendors doing a crappy job. Often because they think front end dev is beneath them. Many developers are craving better CMS's in this regard and if PHP can lead the way it will benefit the language greatly. All mailing lists and fora on web design and front end dev are littered with questions like where can I find an CMS that produces good markup! c. One could also argue that there is no such thing as well written PHP-code implemented on the web today... Since *most* of it is crappy! The web is a tagsoup. We try to use as semantically correct markup as we can, but there is no way in h3ll everyone can write strictly valid pages. We shouldn't need doctors degree in markup to write web pages. C'mon, it isn't that hard! There are plenty of things in PHP-land that are much harder to learn. And if someone has a specific markup related question for the manual, I am willing to answer them. Just CC me since I am mostly lurking on this list. What PhD does is to convert extremely semantically correct XML to (x)html(-ish) markup, injecting eRDF (and some microformats) semantics where it can to further improve the semantics. There is no way we can possibly make all pages valid. PEAR requires all code to follow certain conventions. So does almost every other well established app. Why isn't that considered impossible or unnecessary? Besides, there are tools to help us. CodeSniffer and Tidy. JSLint and validator.nu. Etc. In fact, PhD is already quite well on the way to have really good HTML. As long as the browsers understand the markup and present it relatively alike then I am satisfied. I really do not see the point in wasting hours (and performance) in working around block elements inside inline elements, or nested paragraph tags. Valid and semantic code is not only about rendering. It is about ease of maintenance, ease of finding and fixing errors, ease of enhancements. And I seriously doubt that anyone can provide a case where correct markup degrades performance - where the markup is the culprit. Right now Google, Yahoo and others spend lots of time investigating web performance. No expert on this belittles the importance of semantic and valid code! Browsers have implement this since the beginning. With HTML5 the invalid markup will become consistently rendered in the browsers and that is all we need; consistent rendering. Isn't that the defense of a PHP developer who dislikes using patterns, coding standards, etc? It works - that is all I need. Let's also remember that even though HTML specifies how browsers should treat non conforming markup, no browser yet follows the HTML 5 parsing rules. (Mozilla has started their work, hiring Henri Sivonen to lead it, but they are far from finished.) PhD users will not benefit from this particular part of HTML 5 for many years yet. In todays browsers invalid HTML really do cause unpredictable results. (Valid code do cause that as well, though, because of browser bugs... But to sligthly lesser degree.) And what about accessibility? Consistent rendering for normally sighted users on a PC or Mac is not the same as fully working for people using assistive devices, small screens, etc. I'm not saying that I'd veto patches to fix PhD rendering, but at the cost of massive performance degradation or hours of work... really? Should we really bother? Once again: Massive performance degradation? Not true. Lets rather spend some time on researching the various RDF vocabularies that we can implement using RDFa or eRDF, or even microformats, we would gain so much more on that. And having POSH markup as a foundation will very much *help* implementing microformats and RDF! Separating design from content by removing all presentationally oriented elements and attributes and switching to strict DTD (or perhaps HTML 5) is not anything that will prevent PhD from using additional goodies. _ BTW, checking a few random pages in the manual, there are
Re: [PHP-DOC] XHTML
Hannes Magnusson skrev: I don't think nesting p tags are a problem in html5. AFAICT it requires serious willpower to create invalid html5 markup. HTML introduces a new concept: conformant. It distinguishes between what browsers should be able to handle (including bad markup) and what authors are required to do (write good markup). Todays browsers already handle badly written HTML. The new stuff is basically just an effort to make them handle it in a consistent manner, not only as to what graphical result they display, but to what DOM they will produce internally. I.e. it is very easy to create non conforming HTML 5. pfoo divbar/div zoo/p Not conformant. The div will close the paragraph. The intended remainder of the paragraph ( zoo) will not be part of it. Neither styles or DOM-manipulation will apply to it. The text will be a sibling node to the paragraph. The end tag will simply be discarded. This is non-conforming markup. An HTML 5 validor, such as the one being written by Henri Sivonen (http://validator.nu) will complain. In fact, HTML 5 does __not__ lessen the rules on validation. Au cointraire: The rules as tightened up. The following is illegal: div pfoo/p embar/em /div One must not mix block elements and inline elements or plain text, as children to a block element. Lars Gunther
Re: [PHP-DOC] Suggested text for the Tidy example
Hannes Magnusson skrev: Is that text copypaste from that book? If so, we can't use it. If not, cool! You may use it. I am the humble author. I saw one typo: Notice that the dfn and em tags now are correctly nested Should be: Notice that the span and em tags now are correctly nested (In my experience back-end devs usually know too little about good front end code and I only suggested a way for the manual to be even better than the O'Reilly book...) If I'd like to check out from the CVS using Eclipse using the team-extension, what would the settings be? Host:cvs.php.net Repository path: User:cvsread? Password: (clear) Connection type: pserver Default port Lars Gunther (BTW, I've had trouble getting XDebug to work correctly in Eclipse. If someone could help me through IRC or some other IM I'd be willing to pay up to 50 USD for that. Answer off list, of course!)
[PHP-DOC] Suggestions about Front End code examples
Hi Today I polluted the internals list with an off topic remark about Front End code quality. I quote myself: [Off topic rant] I am constantly amazed that some PHP-wizards, whose knowledge of back-end development clearly shows in how many ways I must still be considered an newbie, are very unaware about what has been going in on the front end this century, with regards to accessibility, standards, unobtrusive scripting, semantic (X)HTML, CSS-based design, etc. [/rant] Now, things might improve if the manual nudged people in the right direction. I am not thinking about teaching HTML or CSS, but doing the small right things in all examples. E.g. This page: http://docs.php.net/manual/en/introduction.php The HTML in An introductory example should have a DOCTYPE. And always a strict version of either HTML 4.01 or XHTML. I will in a separate mail submit text that may improve this page: http://docs.php.net/manual/en/tidy.examples.php Lars Gunther
[PHP-DOC] Suggested text for the Tidy example
Page in question: http://docs.php.net/manual/en/tidy.examples.php Suggestions (summary): 1. Change the example to use a strict doctype, and include the output from the script. 2. Explain what has happened 3. Give another example where a different type snippet is corrected 4. Explain what has happened 5. Give a third example where valid, but un-semantic, code will not be made semantic, to show how one still needs to consider proper usage, even though tidy is being used. (The chapter on Tidy in PHP Cookbook by O'Reilly gives a really faulty explanations in this regard.) --- Suggested text: --- The script above will output: !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd; html xmlns=http://www.w3.org/1999/xhtml; head title/title /head body a html document /body /html Notice how the missing doctype and missing XHTML-tags have been added, in this particular example the head, title and body-tags. The result is well formed XHTML. Indentation has also been added. However, in this example Tidy still fails to produce entirely dfnvalid/dfn XHTML 1.0 strict, since any text in the body must be inside a block-level element, and tidy will not guess what block-element it should use. But Tidy can give a warning about issues like these. Adding the line echo $tidy-errorBuffer would produce the following warnings: line 1 column 1 - Warning: missing !DOCTYPE declaration line 1 column 7 - Warning: plain text isn't allowed in head elements line 1 column 7 - Warning: inserting missing 'title' element Example 2 [Code to be cleaned follows, same script in PHP] !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd; html xmlns=http://www.w3.org/1999/xhtml; head titleA second example/title /head body p Badly spannested em class=fooand/span missing tags./p /body /html This script will output: !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd; html xmlns=http://www.w3.org/1999/xhtml; head title A second example /title /head body p Badly spannested em class=fooand/em missing tags./span /p /body /html Notice that the dfn and em tags now are correctly nested, and that quotation marks have been added to the attribute value. The missing closing tag for the em-element has been added as well. This code will now validate. Example 3 ?php ob_start(); ? !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd; html xmlns=http://www.w3.org/1999/xhtml; head titleA third example/title /head body pabbrValid/abbr, but citemisused/cite use of HTML/p centerWell formed, but font face=Verdanaunsemantic/font HTML/center /body /html ?php $html = ob_get_clean(); $tidy = new tidy; $config = array( 'indent' = true, 'output-xhtml' = false, 'doctype'= 'strict', 'drop-font-tags' = true, 'wrap' = 200); $tidy-parseString($html, $config, 'utf8'); $tidy-cleanRepair(); echo $tidy; This code will output: !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01//EN http://www.w3.org/TR/html4/strict.dtd; html head title A third example /title /head body p abbrValid/abbr, but citemisused/cite use of HTML /pWell formed, but unsemantic HTMLbr /body /html In this example we converted XHTML to HTML 4.01. Tidy can be used for conversions in either direction. The namespace attribute was removed. The elements center and font, now obsolete and better replaced with CSS, have been removed from the markup, thanks to the setting drop-font-tags. Notice that Tidy will not drop these elements unless this explicitly has been mentioned in the settings, even though they have been completely removed from HTML 4.01 strict and XHML 1.0 strict and later. Tidy will not deduce such behavior from the doctype chosen. Tidy can remove some unsemantic markup, but it cannot check that an author has used (X)HTML elements properly from a semantic point of view. Even so, this extension is a powerful tool to check for most and correct some markup errors. -- English question: Is it A HTML doc or AN HTML doc (one speaks HTML with a vowel sound first...)
[PHP-DOC] Ctype and PHP 6
Hi again! And please forgive a relative newbie on the list for asking dumb questions. Am I correct in assuming that the ctype-family of functions neither is nor will be available with Unicode support in PHP 6? If so, it should perhaps be stated in the manual that these functions are not future proof. (Perhaps they even should start spitting out an E_DEPRECATED error in PHP 5.3?) As in: [ Note: Builtin support for CTYPE will be removed in PHP 6 ] Lars Gunther
[PHP-DOC] Documentation updates as RSS
Hi again! I tried the site and Google to no avail. Here is my question: Can I get all updates to the manual as an RSS or ATOM feed? Or do I have to implement my own? Lars Gunther
[PHP-DOC] Base 64
Hi again! The manual does not explain if there is any difference whatsoever between: base64_decode and imap_base64 and base64_decode and imap_binary a. Is there? b. It should - IMHO - give some advice on this issue. Lars Gunther
[PHP-DOC] The Swedish manual lags behind
Hi all! 1. Please do not take this as some kind of bashing. I do respect that all work on PHP is done by volunteers and that time is hard to find for us all. Even so for me. I do not have the time to contribute to the manual right now. I will lurk on this list and maybe things might change in the future, though. 2. However, I do find it annoying that I constantly have to remind my students never to use the Swedish version of the manual, which basically is not a translated, but an outdated version(!) of the English one. Compare: http://se.php.net/manual/sv/function.date-default-timezone-set.php To: http://se.php.net/manual/en/function.date-default-timezone-set.php Is there a way to automatically update the (not so) Swedish version? Or may I suggest that it be dropped? As it is right now i think it adds more confusion than value. Since the PHP website identifies my language preference (or maybe uses some geo-ip system) I constantly find myself on the Swedish language version of the manual and have to change version manually (OK, so it's just one click, but i have to do it often. And my students keep forgetting to do it.) Lars Gunther
Re: [PHP-DOC] The Swedish manual lags behind
Sean Coates skrev: The point that seems to be bothering him is a toss-up between exactly what this thread is about and killing off old translations that may or may not have some valuable translated content (plus the fact that it looks nice to have a ton of translations). A badly done translation quickly makes things look less nice... the compromise might be too keep the introduction, that really is translated and redirect the rest to the up to date English version. If the encoding issues get solved, that is! Example: http://se.php.net/manual/sv/getting-started.php The heading should read: Komma igång i.e. with LATIN SMALL LETTER A WITH RING ABOVE Unicode point 00E5 And please do clearly mark some translations as partial! BTW, Sean, i enjoy the podcast! Lars Gunther P.S. I suspect that the main reason there is no real demand for a Swedish translation, is that we tend to be very proficient in the English language. We do not dub movies or TV-shows. On my last (and only) visit to California everyone kept asking me if I was from England. I've got many friends who can tell similar stories.
