Re: Translating PHP error messages (fwd)

Disclaimer: US English _is_ my mother tongue, but I've learned both some spanish (I live in Arizona, USA) and some german (5 years in school) and am currently working on a large, 38 language/dialect, website project, with translations from US english to UK english, Mexico Spanish, Chilean Spanish, Guatemalan Spanish, Russian, Greek, Urdu, etc. etc. Zeev Suraski wrote: > IMO, we can add a unique identifier to the error message handler, and keep > the error text in English. This will allow us: > (a) To still understand bug reports or problems without having to look > errors up in some cross reference (note that it doesn't concern just us, > but posts on php-general as well - people often help each other there with > problems) > (b) To describe error messages more thoroughly in external documentation > (i.e., give possible causes for this error, what exactly it means, things > that don't usually fit in the one line description built-into the error). > (c) If (b) happens, it can be translated to whatever language the > documentation teams support. Wonderful idea, as it also allows for error translation changes/updates on the fly (without a PHP recompile). I also think this is of much greater value to international code users, as it allows for an ISP in, for example, Belgium, to refer to something much more portable than a single language/dialect of the area. Some locations have two to five regional languages... should they install the french RPM? The german RPM? The english RPM? Which dialect? Cynic wrote: > Try to translate "flex scanner error" into your native language. > Will it be any easier to understand? As a *native* english speaker, I can't say I really understand it. :-) (bending imaging error? muscle-harden reading error? bending camera error?) > Yes, PHP could definitely use somewhat more intuitive error > messages... Well, some could be changed. Keep in mind that the best programming minds are not always the best UI minds, so their skills should not be focused on communicating to the newbie level.... this is why there are separate PHP documentation and code maling lists, CVS areas, etc, because handling a code error, and communicating the same error to new users, are not the same thing. That's not a problem, it's a *good thing* to have different people focusing on different aspects. I'd rather have the dev core focus on improvements to the language, and doc core focus on improvements to the understanding and comprehension of the language. I don't mind the terse error messages, because they *reduce* the amount of reading I have to do when debugging a script.... the same kind of paradigm exists in the online manual, where there are terse reference descriptions, and verbose errata and introduction sections for users who need more information. > PHP could either display error messages in both English (always), > and another language (optional). > Or display the english version, and a link to the localized > version (ala the link to PHP credits on phpinfo() generated > pages). This is, of course, awfully webcentric. PHP is very much a webcentric language to start with... but combined with a number (to help generate the link), this gives users both an ability to increase verbosity for those who need it, and decline verbosity for those who don't. (Downloadable versions would be essential as well...) To somebody who already knows what "flex scanner error" means, they don't really need to see a long description, written in any specific dialect or language. To somebody seeing it for the first time, it's a foreign language statement anyways, and they will likely benefit from having a verbose translation available, even if it's only having an english one. :-) So, I would have to suggest that we provide more error information, in online, translated versions. The web-link idea definitely increases the usability of the error code. -Ronabop -- Personal: ron@opus1.com, 520-326-6109, http://www.opus1.com/ron/ Work: rchmara@pnsinc.com, 520-546-8993, http://www.pnsinc.com/ The opinions expressed in this email are not neccesarrily those of myself, my employers, or any of the other little voices in my head.