Re: [PHP-DOC] Re: [HEADSUP] Call for help
Based on what I've read recently, my co-worker (Rafael Dohms) and I started to think about a possible meeting of UG here to help with documentation. Now that PHP TestFest is over, we should try the PHP DocFest. =) What do you think? It's a great idea but should happen after the php.net migration to SVN settles and the issue of translations is solved. It could also be a big part of the "Call for help" and also have nice side effects like spawning a better doc HOWTO and/or "Get Involved" section. Regards, Philip
Re: [PHP-DOC] Re: [HEADSUP] Call for help
With the new editor online why change to po? More work lost and more markup changes? Sorry but each time that en make a change like this is less people on translation, and days of work only to update to a new system. Will be more one system to mantain, more time lose on doc build, phd did a great work on reducing it and making it simple, now increase it again and make a lot more comples again? So: will be a en file, this file is converted to po, i have to see the diffs in en po, do it in pt_BR, convert my file again to xml, build it. If there is a kind of auto update tool like the used for po will break many langs, po is usefull for short messages for text is horrible. At last make a option for everyone who want keeps working direct on xml files and not on pot. Fernando. Okay, I'll summarize why I feel a gettext approach is good. If I misunderstand the situation then _please_ say so as I am not an expert on translations. The bottom line is our current system is archaic, broken, and in need of a major overhaul. However, we don't need to rush into anything but I figure using po files would be a good base. So: - Today a markup change to EN easily breaks translations - Today adding a new section (any id) likely breaks translations - Many tools exist for editing po files - Many tools offer statistics for po files - I presume it's easier to do things like: --- "if file x is 80%+ translated and up to date, build, else show EN" --- Or, fine tune it further, paragraph by paragraph (wise? weird?) - Translators can focus on translating and not DocBook or markup --- Ex: As of one minute ago, 5/11 of our 'active' translations are not building. I doubt any of the 20 others do at all. - Better translation tools are available with po files, like for TM and CAT - Other people use it, so maybe it's the cool thing to do - Since other people do it, we can steal their tools and ideas Our current system is not working. We have two translations that can be considered fully "up to date" (JA and FR). And now to summarize reasons why we should not use PO files: - Longer build time for docs - Must learn something new - Must create new tools that help deal with them - Deal with contextual issues in PO files A few problems we must solve: - Most translations are dead or have little life -- yet the global PHP community is huge - Translators shouldn't have to worry about Markup (DocBook or otherwise) - Changes/additions to EN shouldn't break translations - Today we require CVS Revision numbers, which won't exist in SVN (CVS- >SVN is coming this month) Rant: I'm baffled by how little attention the topic of translations receives in the Open Source world. It's treated like an afterthought when really it should be central to everything. All efforts appear as hacks including the use of po files for a manual. This is sad. Or, did I miss the memo? /Rant. So to reply specifically to Fernando's concerns: Although some markup still exists within translated strings (in the PO files), I figure typically translators building the translation won't be necessary. We could setup a system to do the build and yell at the translations list when it's broken, or something similar, but point is I don't see this as a block for translations. I imagine a translator opening a PO file and translating very fast and not worrying about much else. Also, I don't think having multiple options (XML or PO) for translators is worth the effort. What do people think? It's now or never. Questions? Suggestions? Other ideas? Regards, Philip
Re: [PHP-DOC] Re: [HEADSUP] Call for help
Hi guys, Based on what I've read recently, my co-worker (Rafael Dohms) and I started to think about a possible meeting of UG here to help with documentation. Now that PHP TestFest is over, we should try the PHP DocFest. =) What do you think? Cheers, 2009/7/6 Fernando Correa da Conceição : > Philip Olson escreveu: >> >> On Jul 5, 2009, at 2:53 PM, G. T. Stresen-Reuter wrote: >> >>> >>> On Jul 5, 2009, at 2:57 PM, Peter Beverloo wrote: >>> With the documentation moving to PO files soon (as well as changes around the PhD editor GSoC project) >>> >>> I follow this list pretty closely but I must have missed this (rather >>> important) news item. When will the documentation move to PO files? How will >>> this change the translation process and source files? Is this move >>> documented somewhere? In short, is there an other list where such decisions >>> are made that I'm unaware of? >> >> Several translation related discussions have taken place on the subject >> although typically they have been short threads. The English documentation >> process will not change as PO files are only used by translations. The >> process has been poorly documented (by me) but is moving forward. It's a bit >> chaotic especially considering the rush to get it done before the project >> moves to SVN but here are a few recent threads on the topic: >> >> - http://markmail.org/thread/iqxkiekmvz6h43lt >> - http://markmail.org/thread/kidqiimuglh2tmfh >> - http://markmail.org/message/fduqvora3lef4cit >> >> A test repository with PO files are in CVS although they are only English >> (POT) and Japanese as it's purely for testing purposes: >> >> - http://cvs.php.net/viewvc.cgi/phpdoc-po/ >> >> How PO files will be managed is still up in the air but we're in the midst >> of testing out several systems including: >> >> - http://www.transifex.net/projects/php/ >> - http://translate.php.net/ >> >> Neither of the above work today as our project appears too large for >> transifex.net to handle (today, they are discussing how to solve this) but >> they offer a system that could coincide with whatever else we choose as it >> offers help from an additional translation community. And our Pootle setup >> (at translate.php.net) is sketchy with a strange bug (thanks to me) but once >> Michael has time he'll look into it as my sysadmin skills sit right around >> null. >> >> So that's the situation. Given the mere size of this move, the SVN rush, >> and my lack of knowledge (but it's interesting to learn this) I'm afraid it >> won't go smoothly. All help is desired, as are questions and/or answers. >> >> Regards, >> Philip >> > With the new editor online why change to po? More work lost and more markup > changes? Sorry but each time that en make a change like this is less people > on translation, and days of work only to update to a new system. Will be > more one system to mantain, more time lose on doc build, phd did a great > work on reducing it and making it simple, now increase it again and make a > lot more comples again? > So: will be a en file, this file is converted to po, i have to see the diffs > in en po, do it in pt_BR, convert my file again to xml, build it. If there > is a kind of auto update tool like the used for po will break many langs, po > is usefull for short messages for text is horrible. > At last make a option for everyone who want keeps working direct on xml > files and not on pot. > > Fernando. > -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com URL: http://blog.bisna.com São Paulo - SP/Brazil
Re: [PHP-DOC] Re: [HEADSUP] Call for help
Philip Olson escreveu: On Jul 5, 2009, at 2:53 PM, G. T. Stresen-Reuter wrote: On Jul 5, 2009, at 2:57 PM, Peter Beverloo wrote: With the documentation moving to PO files soon (as well as changes around the PhD editor GSoC project) I follow this list pretty closely but I must have missed this (rather important) news item. When will the documentation move to PO files? How will this change the translation process and source files? Is this move documented somewhere? In short, is there an other list where such decisions are made that I'm unaware of? Several translation related discussions have taken place on the subject although typically they have been short threads. The English documentation process will not change as PO files are only used by translations. The process has been poorly documented (by me) but is moving forward. It's a bit chaotic especially considering the rush to get it done before the project moves to SVN but here are a few recent threads on the topic: - http://markmail.org/thread/iqxkiekmvz6h43lt - http://markmail.org/thread/kidqiimuglh2tmfh - http://markmail.org/message/fduqvora3lef4cit A test repository with PO files are in CVS although they are only English (POT) and Japanese as it's purely for testing purposes: - http://cvs.php.net/viewvc.cgi/phpdoc-po/ How PO files will be managed is still up in the air but we're in the midst of testing out several systems including: - http://www.transifex.net/projects/php/ - http://translate.php.net/ Neither of the above work today as our project appears too large for transifex.net to handle (today, they are discussing how to solve this) but they offer a system that could coincide with whatever else we choose as it offers help from an additional translation community. And our Pootle setup (at translate.php.net) is sketchy with a strange bug (thanks to me) but once Michael has time he'll look into it as my sysadmin skills sit right around null. So that's the situation. Given the mere size of this move, the SVN rush, and my lack of knowledge (but it's interesting to learn this) I'm afraid it won't go smoothly. All help is desired, as are questions and/or answers. Regards, Philip With the new editor online why change to po? More work lost and more markup changes? Sorry but each time that en make a change like this is less people on translation, and days of work only to update to a new system. Will be more one system to mantain, more time lose on doc build, phd did a great work on reducing it and making it simple, now increase it again and make a lot more comples again? So: will be a en file, this file is converted to po, i have to see the diffs in en po, do it in pt_BR, convert my file again to xml, build it. If there is a kind of auto update tool like the used for po will break many langs, po is usefull for short messages for text is horrible. At last make a option for everyone who want keeps working direct on xml files and not on pot. Fernando.
Re: [PHP-DOC] Re: [HEADSUP] Call for help
On Jul 6, 2009, at 7:31 AM, Nilgün Belma Bugüner wrote: Pazartesi 06 Temmuz 2009 02:49 sularında, Philip Olson şunları yazmıştı: A test repository with PO files are in CVS although they are only English (POT) and Japanese as it's purely for testing purposes: - http://cvs.php.net/viewvc.cgi/phpdoc-po/ These pot files don't seem to be generated with the latest version of po4a [1]. If they were, they would be containing the contents. Also when generating the translation po file, this latest version does not complain about the missing or redundant inline tags. You can get more translation through if you use the latest version of po4a. Nice find. Yeah, version 0.34 was used but 0.36 now exists. Regards, Philip
Re: [PHP-DOC] Re: [HEADSUP] Call for help
Pazartesi 06 Temmuz 2009 02:49 sularında, Philip Olson şunları yazmıştı: > A test repository with PO files are in CVS although they are only > English (POT) and Japanese as it's purely for testing purposes: > > - http://cvs.php.net/viewvc.cgi/phpdoc-po/ > These pot files don't seem to be generated with the latest version of po4a [1]. If they were, they would be containing the contents. Also when generating the translation po file, this latest version does not complain about the missing or redundant inline tags. You can get more translation through if you use the latest version of po4a. [1] http://packages.debian.org/source/squeeze/po4a Best regards, Nilgün
[PHP-DOC] PhD Improvements (Plugin System) - Status Report 6
hi all, This is my 6th status report (28 June to 04 July). HIGHLIGHTS - This week was very productive, I wrote all the xhtml formats from the PHP Package (chunked, big, web, howto) and the manpage output format (functions) \o/. Now I have to port the PDF and CHM formats. After that, tests and remove the old code from HEAD (maybe a new release? :) ). Now is time to make the midterms evaluations. KEY ACCOMPLISHMENTS - New classes: Package_PHP_XHTML: Base class of the xhtml formats Package_PHP_BigXHTML: Big html format Package_PHP_ChunkedXHTML: Chunked html format Package_PHP_Web: The .php chunked format Package_PHP_HowTo: Other .php format Package_PHP_Functions: The Manpage output format \o/ Format_Abstract_Manpage: Abstract base to the manpage format Pakage_Default_Manpage: Class with the (element|text)maps and format_ functions Implemented the functionality(refs, classes, vars) of the mktoc.php file using the SQLite Indexer. Now we don't need the mktoc file. Bug fixes in the Default Package. MY TODO - Fix bugs in the PHP Formats Begin porting the PHP themes: Package_PHP_PDF Package_PHP_BigPDF Package_PHP_CHM Package_PHP_KDevelop Write the Abstract Formats: Format_Abstract_PDF --- You can find my schedule here: http://wiki.php.net/gsoc/2009/phdplugins Blog: http://moacirdeoliveira.blogspot.com Regards, Moacir de Oliveira
