||*()*|| Hi, Rasmus. RL> Jacques Marneweck wrote: >> Rasmus Lerdorf wrote: >>> Hey, what do you guys think of taking advantage of our big >>> international doc team to translate the main web site pages as well? >>> It is a much smaller project than translating the manual and we >>> already have the language choosing mechanisms and everything in >>> place. The biggest problem is figuring out whether we should try to >>> pull the text parts out of the current pages and keep them somewhere >>> separate, or simply clone the pages in individual /en /fr /de /ja >>> top-level directories. >>> >>> -Rasmus >>> >> One also needs to look at the aspect of do we have the requirement where >> content is first added to the english version of the php.net website >> prior to it being translated or can translators add news to say the >> french version of the site and then to the english?
RL> I think we need a single point of reference for news items, so yes, RL> adding first to the English one so everyone can review makes sense. RL> -Rasmus How about local PHP news and conferences? I know in russia there is a big PHP communtity, what uses russian language and organizes their own russian based conferences. Not too much people uses PHP.NET site for anything else than download and manual. For most russian language auditory monthly conference and training invitations available from PHP.NET site at the moment do not make sense at all and I do not see much sense in translation of local USA or China events into russian and russian local events announcements into english. PHP.NET must be personalized to be useful for everyone, so everyone can choose what to read in preferences. Good translation system must be wiki-template-based with an ability to maintain one-to-one mappings to docbook or to fictional simplified phpdocbook XML schema (where this schema still will be clearly one-to-one mapped to docbook) to continue generate documentation in various formats. This needs time and clear RFC/functional/technical and/or architectural documentation, because such a project can not be done by a one man army on a volunteer basis. Current php-web code is scattered among master, main and phpdoc and to realize how it works one has to spend some time. Needless to say, what core PHP.NET maintainers deny integrating patches, what they do not have time to review and this is the reason why featurecreep is not welcomed. PHP.NET is quite in stasis, because it's web code probably is not structurized enough, lacks documentation, is not easy to maintain, understand and keep in mind. PHP.NET needs some API or common description of it's reusable components and how they fit together if it is aimed to expand developers base. Even if we will make advanced translation service - somebody has to update news items and it likely will be people, who is not burdened with daily programming too much - good translators are often those, who don't realize what CVS account is about and why to ask for it. PHP.NET must revise it's policy to be community friendly and have to decide which kind of environment it would like to create - limited professional only cathedral or chaotic user friendly bazaar. The project like this system can turn out very complex and without developers it will not be available anytime soon (see livedocs for example of idea and good, but unwieldy code). Seems like PHP.NET need more full-time support/developers as much as abandoned zend php-collaboration project. t --
