>I am definitely -1 for this idea. XML is a buzzword, it is >good in some cases >not so good in others, definitely not a one size fits all >solution. In PHP's >case it would add decency on an XML parser, make life of >developers adding, >modifying, removing error messages difficult and just like the >documentation >will seriously lag behind the primary (English) localization.
As I mentioned via Shane's comments... XML isn't really the crux of the matter here, I'm more interested in the concept than implementation. I'm interested in hearing what libraries and techniques Shane has in mind. >just adding more to the pile will drive some users away. RAD (Rapid >Application Development) gets you only so far eventually for >large scale >applications speed becomes essential and if Perl, Python, C >can offer it then >those languages will be picked over PHP. I understand your issue, and If the system can't be implemented without a huge performance hit then we're in agreement. Perhaps the issue here is that I think the performance hit that could be taken can be limited almost completely to the occurance of an error, rather than during normal operations. >What will happen to localized error message when the charset >of the page they >are displayed on does not support the charset required for >proper rendering >of the text? Most likely gibberish. Well, obviously if you are writing a French web site it only makes sense that your error messages would be in French. Why the heck would you write a french site with German error messages? >If you have a constant for every error would that not mean you >will need to >register hundreds if not thousands of constants at run time at >an enormous >CPU & memory cost? Absolutely not. The error constant / values themselves could be #defined, requiring absoultely no CPU/memory cost to speak of. Regarding the back-reference, although it could be implemented in memory as a lookup table this could be stored in a file which is only referenced in the event of an error. >> This would be simple to implement, and no more of a hassle >to maintain >> that what already exists however still provides enough >information to >> the development/QA teams (we know the type, the module, and >the actual >> error which occurred) yet still allows the developers who aren't >> english-speaking to still have some clue as to what the heck >happened >> with their script. >> > >How do you figure that it would be just as easy to maintain? >Right now adding >an error is just a matter of writing the English text inside >the C file I am >working on. By having messages localized they'll need to be >stored else where >XML, gettext database and so on... meaning that there is >already more for the >developer to do. Well, it'd be easier to maintain because you wouldn't have to know a darn thing about C, or have to dig through thousands of lines of code in order to find this php_error() line that contains the error message. Placing the error information is a hair more difficult for the developer, who has to actually open up a separate file or two to add their constants.... But that's hardly a serious issue IMHO. John -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
