Difference between revisions of "Module Development Collaboration"
(→Directory structure: added fixes directory, moved metadata to module root dir)
|Line 1:||Line 1:|
== Directory structure ==
== Directory structure ==
Revision as of 07:27, 30 August 2015
. CrossWire will provide to module teams who want to collaborate on a module following tools:
1) A private Git repository - access will be via SSH keys which can act as a scrapbook and collaboration tool 2) Email notification system - all changes to the repository are automatically notified to all collaborators 3) Some templates for the repository and a bunch of scripts to make module making easy.
If you want to get such a repository please email to modules AT crosswire Dot org.
- orig -- source docs from publisher/author
- fixed -- source docs after correction of errors, inconsistencies, etc. in text or markup
- docs -- documentation, correspondence with pubs/authors, permission letters, etc.
- sword -- compiled Sword module
- gobible -- compiled Go Bible applications (including any smaller collections)
- epub -- EPUB for publishing to ebooks
- osis -- OSIS docs for osis2mod or sharing with publisher/3rd parties
- thml -- ThML for import to Go Bible?
- usfm -- USFM for sharing with author or as an intermediate step in conversion
- usx -- USX for sharing with author or as an intermediate step in conversion
Contents of "module" directory
The module directory (e.g. GerElberfelder above) would contain all module-specific scripts necessary for converting source files to modules and other output formats. So general purpose scripts like usfm2osis.pl would not appear here, instead being installed at some system-wide location outside the sword-modules tree.
Following the approximate lead of Sword SVN, keep a ChangeLog for each module in the format:
[date in ISO 8601 format: yyyy-mm-dd]\t[contributor name <contributor email>]\n \t[comments]
Let's use either GNU make for running scripts or possibly something more platform-independent like a Python or Perl script that calls other scripts. Ideally, we should be able to issue commands like:
make clean (delete all output & intermediate format files) make all (make all supported targets: Sword/OSIS/EPUB/ThML/USFM/...) make sword (make Sword module plus any necessary intermediate formats, e.g. USFM & OSIS) make epub (make EPUB module plus any necessary intermediate formats)
Metadata should be collated into a single file (maybe something XML to facilitate validation for automated generation & parsing) the incorporates all necessary metadata for all of our output formats (OSIS, ThML, TEI, EPUB/MOBI, Sword). Investigate Dublin Core & other metadata standards. Consider developing a set of private-use extensions to an existing standard and consistent methods of encoding all of our relevant .conf values in OSIS/ThML/TEI files.