Due to the nature of the web, people from different nationalities can reach websites. Large websites and portals usually have the content available in multiple languages. On a static website or where the content is tightly controled by a maintenance team, the content can be updated as the changes are made by the team dedicated to it.
When it comes to a collaborative websites where any user can add content, the translation process becomes much more complicated. Since the modifications can be done at any time and the author of the modifications probably can’t translate in all languages, the pages which are supposed to contain the same content end up having huge differences. A good example of this is Wikipedia, which is a great website with tons of content, but sadly, most of the content is only available in english. It’s not rare to see a page where the english version contains 10 printed pages of content while the french version barely has one.
The rest of this post contains more details about the problems and ideas to improve those websites.
Read more…
I just felt on a page dedicated to XForms on php.net. It’s pretty much only information as nothing special is required, but the method is still interesting. Since XForms sends the data as XML as the POST data for the HTTP request (as raw data). If always_populate_raw_post_data is set to on (which is not a default setting), the data can be accessed from $_SERVER['HTTP_RAW_POST_DATA']. Using this setting will cause PHP to always populate a variable with data that could be large, which would cause slow downs with time. Instead, you can read the data from the input stream when required. Once you have the raw data, you can simply use your XML parser of choice to read the content.
<?php $fp = fopen( "php://stdin", "r" ); $data = ''; while( !feof( $fp ) ) $data .= fgets( $fp ); fclose( $fp ); ?>
Even if XForms is not currently supported in browsers, it’s already used by multiple applications and should soon become an important standard in application communication. Of course, the traditional URL encoded POST data does the job, but XML simply opens more possibilities, such as validation against an XML Schema. It’s also a lot easyer to implement for a common application. All languages have XML libraries ready to use.
As a side note, I also noticed a section on security which gathers the most important concepts to be aware of during development. It seems like a response to multiple articles on security that have been written recently. Having all those informations centralized can’t be a bad thing.
One of the common complaints I see about Linux and Open Source in general is that there are no standards in the way things are handled. The most frequent example is the packaging systems that are different between distributions. You probably already heard things like They should do it this way!
with a lot of vision and knowledge of the actual problems and situation. I think the real problem actually comes from those same idealistic people. Their ideas aim to unify the way things are made, but the new project they create simply becomes one of those other distributions.
There are currently two major trends: Debian’s apt-get style installers and RedHat’s RPMs. Distributions simply adapt the packages to their own needs and vision. Most distributions aim toward a different audience, have a different vision on what a release process should be and what is acceptable. Debian has very high quality standards and has a long release process. Gentoo intermediate to advanced power users with general knowledge of Linux. Mandrake is all about user-friendlyness. Xandros wants to be like Windows. YellowDog is for Macs. Each distribution has it’s own favor and it’s just fine as it is. As long as an application can be compiled on all of those systems, there is no problem to be seen. Isn’t the good old source code the most portable solution?
Your operating system shouldn’t tell you who you are or what your preferences are. Choose what you are comfortable with.
With the new set of W3C standards implementation coming up, it feels like the browser war will get a second round. The Mozilla project has been very active with the SVG support and the results are very impressive. Web applications will be more dynamic than ever. The problem developpers encounter is that very few browsers actually support this new technology and millions of Internet Explorer users will be left behind.
Is there a real problem? All Gecko browsers are Free and accessible to anyone on about all known platforms. Is there anything wrong in asking for requirements on an application? The website can remain accessible even if not all fancy effects are present, but this goes back to having two versions of the application, but this is simply a normal transition phase. Overhead is always present when major changes occur. It wasthe same thing during the 16->32 bit transition, until JavaScript stabilized and even right now, 64 bit processors support the 32 bit instruction sets. It’s simply a sacrifice that has to be made. Unless people actually use those technologies massively, they simply won’t spread and we will remain stuck with the current partial CSS2 support.
SVG is only the tip of the iceberg. Mozilla’s XForm implementation, which is supposed to replace the forms in XHTML 2.0, has already begun. A few elements CSS3 start to appear. Right now, XHTML 1.1 is impossible to use if IE support is required. Can a sinlge browser really slow down the technology development process?
We can only hope Microsoft will release a new version that at least comply to the standards soon. I wouldn’t expect new technology anytime soon.
Mozilla has been mentionned a lot, but the growing popularity of Macs since OS X also helps the cause. Safari also offers good support for new technologies.
As a default behavior in PHP 5, using an object in a foreach structure will traverse all public values. Multiple Iterator classes are available with PHP to allow you to iterate through common lists, such as directories, XML structures and recursive arrays. It’s possible to define your own Iterator classes by implementing the Iterator interface, which will override the default behavior. Using this method will allow great flexibility in data management and give a great opportunity to draw a line between display logic and buisness logic without having to generate an array containing all the data as it was required before to use foreach.
It also avoids using the while loop method which was based on the fact that a function could return values of multiple types. It’s not a bad method on it’s own, it actually loops clean enough, but if PHP ever want to be able to interact with other languages naturally, or the other way around, those methods are to be avoided.
The remaining section describes the technical aspects of the Iterator interface.
Read more…
I decided to move from TikiWiki. Even if it’s a great project, it does not suit my needs very well as it contains way too many features and this website does not aim to build a community. The rare few readers probably know that it’s mostly inactive and only contains a few random ideas. A blog will allow me to post more often and with less importance.
I went for DotClear, which seemed simple and light. It’s also one of the first applications I felt on.
Anyway, I will continue working on TikiWiki, even if I no longer use it. It’s a very dynamic project with a lot of potential!