The wiki supports email change notifications (including digest mode). See the envelope icon in the upper right side of this page. Individuals can easily track progress for only the translations they care about. Much thanks to Ralf for getting this started.
How to join the documentation and translation teams:
- Contributing to Zend Framework - See #1 to #4.
- Follow our documentation style guide.
- Introduce yourself and interests by posting to the fw-docs mailing list.
The ZF documentation team helps with tasks and projects affecting all versions of the manual. Many tasks require only basic English skills, so we strongly encourage participation by everyone. All documentation team members are also encouraged to help with the English manual. Many edits, improvements, example contributions, and merging of user-contributed comments do not require strong English skills. Content and accuracy are much more important than "perfect" English, and English experts can adjust wording as needed later.
The documentation team has the authority to edit the English manual. Documentation project team members include:
- All Translation project members
- All English manual project members
- All Zend ZF team members
- Andries Seutens - helping with automatic translation of docbook to HTML, docbook to Wiki, and Wiki to docbook (work in progress: http://andries.systray.be/zend-framework/docgen/)
We encourage people to communicate in whatever language they prefer. The language translation team wiki pages support UTF-8, including Japanese and Chinese.
If you see this "[~nocla]", then please ask that person to send a CLA before contributing.
- Arabic (????)
- Brazilian Portuguese (Português Brasileiro)
- Chinese (??)
- Dutch (Nederlands)
- English (help wanted)
- French (Français)
- German (Deutsch)
- Hebrew (?????)
- Italian (Italiano)
- Japanese (Nihongo)
- Polish (Polski)
- Slovak (Slovenská)
- Spanish (Español)
|Need Proactive People|
Compare the organization of our wiki spaces (http://framework.zend.com/wiki/dashboard.action) to http://drupal.org/. Help wanted.
Although the ZF Sidebar helps greatly, the organization and look and feel of our wiki pages could be improved. Drupal's website demonstrates an orchestrated, planned arrangement and organization of content. Their content is somewhat similar to that found in the ZF wikis, so perhaps we can borrow some organizational ideas.
Looking for volunteers to proactively define this team's mission, responsibilities, and tasks.
- Community manages: http://framework.zend.com/wiki/display/ZFUSER/Home
- Community maintains site maps for each wiki space
- Community provides recommendations for changes to ZFDEV, etc. wiki spaces
- Site Map
- Improving organization of wiki
- Make a PDF and HTML copy of the manual available for download.
- Make smaller edits easier, and possible by at least everyone on the documentation / translation teams, possibly including all CLA signers.
- Reduce the learning curve and effort required to make edits to the manual and translations.
- Allow anyone to comment on each section, but with comment moderation, so that the manual can evolve more quickly and with more flexibility than the current process.
- Need notification system for edits (e.g. the wiki "watch"/notifications feature)
- Follow a documentation style guide and proofread before it is released.
- Need to support offline editing of content, ideally with a plain-text import/export capability. Alternatively:
1. Click the "Edit" tab for the page
2. Select all and copy the wiki markup
3. Paste it into my text editor
4. Save a copy as "page title.txt.orig"
5. Save a copy as "page title.txt"
6. Continue editing "page title.txt" [offline] until complete
7. Review the diff of "page title.txt.orig" and "page title.txt", revising the latter as necessary
8. Paste the revised wiki text into the wiki markup tab of the page editor, and save the page
In this way, one can work on the wiki pages offline when needed.
Edits from different authors can be merged using the wiki.
- Quick access: type http://framework.zend.com/zend_controller similar to php.net, where you can easily access a specific function by appending it to the url
- Unreleased incubator documents should be avaiable in wiki, but not added when extracting to HTML and PDF (Maybe tagging or a seperated wiki space).
- Some contributors are writing like "this function can handle xxxx" other as "you can handle xxxx with this function"... note the first person stlye... a defined write style is must and makes the document flow smoothly as a whole.
- Automatically generate HTML and PDF for each language, either directly from the wiki, or from docbook, after auto-generating docbook from the wiki.
Subject: Proposal: Major Change to Facilitate Participation with English Manual
Date: Tue, 05 Sep 2006 13:27:17 -0700
From: Gavin Vess <firstname.lastname@example.org>
I would like to propose a change to how we write the English manual. I
think we have documented numerous cases and examples where the current
process imposes too many hurdles, complications, and effort for those
wishing to use it and contribute. Since the vendor of our current wiki
successfully uses their own product for their manual, including
generating the PDF and HTML, we would like to consider the implications
of switching from authoring content in docbook to using our wiki.
We are proposing opening up the English documentation process to
participation by all documentation team members, and allowing wiki page
commenting by anyone, but with reasonable moderation by the
documentation team members, following in the footsteps of wikipedia. In
order to help achieve consistency, we are also proposing borrowing
mozilla.org's documentation style guide, subject to exceptions you might
The process for adding content and editing the ZF manual pages might
benefit from the use of a wiki that allows user-contributed comments.
How many times have you wanted to make a suggestion or change to the
English manual, but not done so?
Please enter our brainstorm time, where we can openly consider all ideas
to help synthesize a final proposal, before decisions are made.
For the mechanics of this new process, we could setup two new wikis.
One would contain the last official release for public viewing and
commenting. The other would be a draft, work-in-progress with comments
rolled into the body of the page before pages are "released". When we
prepare for a release, changed pages could be copied to the official
release wiki. Then, translators could use the wiki "difference" feature
to see what has changed in the English manual on the release wiki,
without seeing all the interim edits made in the draft wiki.
There might be a wiki plugin that allows tagging and viewing differences
between tags ( http://confluence.atlassian.com/display/CONFEXT/Home ).
If so, such a feature/plugin might eliminate the need for having two
wikis. I am not eager to consider using a different wiki, as it would
significantly complicate user account administration and logins. The
current wiki already supports UTF8 text.
Our current wiki system supports export to PDF and HTML, although the
exports are "plain", and might require some creative manipulation, such
as using Zend_Pdf to beautify it. I agree entirely with recent posts
about the value of providing HTML and PDF downloads for the manual.
Several questions remain, including the docbook import/export process
for our wiki (Confluence):
Also, incubator components using the wiki for documentation would make
documentation available immediately, without requiring the curious to go
through the process of "building the manual". Many of us would like to
help with documentation for the new incubator components. Group editing
of a wiki page has advantages over trying to coordinate editing of the
documentation via SVN.
Research plugins and current efforts to export the wiki to docbook. http://confluence.atlassian.com/display/CONFEXT/Home
Research possibility of tagging pages, such that a PDF could be created
from tagged pages. http://confluence.atlassian.com/x/8hIC - information on features,
including the user manual (in their wiki)
Decide on moderation process / policy for comments.
Any suggestion for improvement is highly appreciated. With a page for
each team the translation coordination could be visible for anyone
outside the team or mailing list. So people might decide to help when
they see some concrete tasks to do, like "Zend_Cache needs to be
translated to French" for example.
Ralf Eggert wrote:
> Hi again,
> another idea just came to my mind. We could even use the wiki for
> coordinating the translation work.
> Each translation team gets his own wiki page. On these pages the team
> can list its members and resume where the team is needing help, e.g.
> German translation team needs your help in the following tasks:
> - initial translation the chapters from English to German
> - Zend_Form
> - Zend_Super_Class
> - ...
> - proofreading the German translation to look for
> - translation mistakes
> - misspelling and typos
> - improve the understandability for
> - Zend_Whatsoever
> - ...
> I am not sure if this is the right word, it should say that
> sometimes a translation might capable of being misunderstood,
> so improvement will be needed.
> In your mail to the general list you could link to these page or even
> pages so that everybody can easily see the current status of each
> translation. The team leaders will then be in charge of keeping this
> page updated.
> The good thing about this is that people who are not in this list but
> want to contribute to the Zend Framework easily can see where their help
> is needed and get in contact with the team.
> What do you all think about this?
> Best Regards,