User:Cjl/Sandbox1

Focus on content

A useful start to buildng a health library can be made by collecting/creating some fairly simple, but nonetheless potentially lifesaving, public health content. The "low hanging fruit" content (WHO, UNESCO, NIH, etc.) that can be used to rapidly bootstrap a health content library is mostly available in HTML or PDF formats. If converting from PDF, I plan to mostly use HTML.

Strive to be application agnostic (mostly)

HTML content will present via Browse, which makes a lot of sense. Other possible choices (e.g. .odt and other open-specification word processor formats would presumably default to Write, except for the fact that Write (or it's parent AbiWord) do not currently support .odt natively . It may be best to be application (specifically word-processor) agnostic.

Internationalization / Localization

Adopting a simple HTML layout will produce content that is readily internationalized and localized via Pootle. HTML appears to be easy to package as a content (.xol) bundle Creating_a_content_bundle.

Content Harvesting tools

There are a variety tools for harvesting HTML content in a semi-automated fashion (e.g. wget) and the files used to internationalize/localize the HTML for www.laptop.org can be used as examples.

• See also http://po4a.alioth.debian.org/

Empower local control of final content

Even after language localization and bundling, simple HTML is generally suitable for further modification before use according to local requirements. We don't have a fancy word for this, but I would coin the term "regionalization" for that aspect of the content life-cycle. This will be necessary to patch up the inevitable short-comings in the cultural-competency or coverage of centrally-produced (essentially generic primer) materials.

• Need to develop and i18n/l10n Simple_HTML_Style_Guide

Widely understood, easily learned, easily edited

The web provides a substantial set of "open-source" samples (e.g. view page source in any browser on any page) that generally allows even novice users to learn enough HTML to perform simple edits (including addition or subtraction of entire text/topic elements). Any text editor will do as a reasonable authoring tool as long as syntax is kept pretty plain-vanilla. Call it "tag soup" if you must, but it works, many web-sites have been built and maintained with nothing more complex than Notepad.

Advanced publication features not really essential

Nearly everyone likes the 'beauty-of-design" elements that more sophisticated layout/mark-up tools can provide, but by-and-large the target textual content are extremely simple documents, some text and a picture or two. There is no point in over-engineering them.

That's my argument in favor of HTML, you are certainly free to use whatever (open) format you want for the content that you plan to contribute, although some are clearly more suitable than others.