Module Submission

Please note: Do not edit this page unless you are actually directly involved with uploading modules onto the server. If you have a comment or addition to make, but you are not part of this particular effort, please use talk page

Module submissions are to a large extent now automated.

To make it simple (and subsequently fast) please prepare your modules in following fashion

1. Please check and validate your OSIS or TEI text. Please create a test module for yourself and check it for typical mistakes:
   1. Poorly encoded verse ranges, empty verses
   2. Wrong Bible book identifiers. The identifiers are not abbreviations in the normal sense - even though they look like English language abbreviations. They are intended to be machine readable internal identifiers. Mistakes will render your module unreadable
2. OSIS texts need to have the CamelCase module name as workID and a 'osisRefWork="Bible"' or 'osisRefWork="Commentary"' entry within the appropriate header section.
3. The document language needs to be set correctly
4. If you can run Perl please run confmaker.pl on your text (found in the repository). Sometimes OSIS texts have spurious tag entries which are picked up by the script and set as module options in the conf file. Our scripts will pick up e.g. the single title element you have not even noticed and they will realise there is a single footnote somewhere - and set the relevant option in the module conf file. To undo this by hand is tedious and will slow down publication. If you do not want your module at this moment in time to have that kind of entry in its conf file, please do not submit texts containing such elements. You may have started a next stage in your module making already - but submitted OSIS texts should be clean and solely containing what you are willing to see published.
5. The preparation of our conf files is automated. Please do not submit a complete conf file, but restrict yourself to the non-calculated elements. If you do otherwise, we will need to delete the irrelevant lines, which is prone to create confusion. Automatically added entries are the [ModuleName] line, all filter options, size, language, data path, osis version, sword version date, minimum sword version, scope.
6. For visual reasons it is good to have your history entries sorted in ascending order at the very bottom of your conf file fragment.
7. As modules are potentially updated for various reasons (tool updates etc) in between releases of new source texts, the module version and the latest history entry should not be in the conf file fragment submitted but in your covering email. These entries added in a different way to your module.

If you do not comply with the above your module submission might end up being deprioritised and will certainly not get uploaded as fast as it could be otherwise