cmahte
commented
7 years ago I'm all for supporting the 3 letter abbreviations (TLAs) in the filename, although the spec the TLA is for the first text row inside the file, not the name (see *USFM spec discussion below.) I have ~100 projects open and this renaming is cumbersome. If you care to act on the Anderson work please own it. I will act on all suggestions here, but they will be delayed, probably by years.
I've built auto renamers in the past (searches inside the file and names appropriately.) However, that technology was done for hire, and when I separated from that non-profit, one of the things I affirmed by signature is that work done directly FOR my employer is not mine, and I could not use that work without permission.
I've updated the Anderson text with all the outstanding items I can remember.
My focus right now is to complete the 1911 Bible (in my own account for now).
There is an another, updated version of the Anderson work. This repo is for the 1864 edition published during his lifetime. (the link at the top of the repo is the actual source used and a visual reference PDF.) If your paper reference is published or reflects the work published in 1917 by his family, with edits after his death, please branch or start a new repository to reflect the difference.
=== USFM Spec Discussion
The latest USFM spec is 3.0, although I still use the USFM 2.4 manual and spec. I have no plans to support embedded tagging in the 3.0 spec, nor the updated 'fig' tag. Otherwise I've implemented the new tags in the 3.0 spec and you might see them appearing (especially the \sd tag.)
The link you sent is still showing 2.4. Because the transition to Paratext 8 is a major change, USFM 3 is also transitional and may take 2-3 years to be fully implemented. That is, Bible projects nearing print (already completed initial translation and moved to back-translation and review), are encouraged to continue with Paratext 7, and NOT upgrade to Paratext 8. Therefore both USFM 2.4 and USFM 3 are "current," until Paratext 7 is deprecated. This isn't scheduled.
USFM 3 can be referenced at:
http://ubsicap.github.io/usfm/
I prefer the paper PDF, which is why I still use 2.4 for reference. The 3.0 spec has no PDF download link. :-(
In the 2.4 manual (with similar wording in the 3.0): if you read section 2.1: the 3 letter abbreviations are spec'd for the slot immediately after the \id tag inside the file. The spec doesn't mention the use of the 3 letters in the filename, although it's nearly universally used by convention.
The "number" in that table IS spec'd for the filename, but includes the words 'may also include' making it a recommendation instead of a spec. The ID number in the spec is very commonly ignored, especially where alternate versification is part of the work.
I've written an organizational recommendation for file naming, but I haven't published nor implemented it. I'll try to publish it soon.
Whenever I do tagging, I concatenate the text into a big file, and apply the initial tags with search and replaces to all books at the same time. This makes for a much more efficient and uniformly applied tags. I then split the books with the unix command csplit. This results in filenames with numbers present, but not the 3 letter codes. The projects on github all follow this method.
Since csplit starts at 00 and increments by 1, that's the officially supported numbering right now. Since the big file is always ordered in published order, the numbers may vary from the spec.
I started using github to track changes, and it appears that filename changes lose the history. If filenames do need to be changed, they should be done as seldom as possible.
For now, the projects should follow this guidelines. I've started a Guidelines Repo and a wiki within that for specification links, clarifications, Best methods, recommendations, etc. However, I don't speak wiki.. so it needs lots of love.
Project names EEE-BX-TTT1111-LLL-SSS2222 Top level Folder names EEE[BX]TTT1111[LLL]SSS2222
Where:
EEE - Language in 3 letter Ethnologue code (ISO 639.2\T). 639.2T takes priority and only if no entry is present, then go to ISO639.3. BX - Type of Scripture
-
B - Complete Bible (including at least 39 OT and 27 NT books, possibly more);
-
B0 - OT (39 books or equivalent complete set for the versification)
-
B1 - NT (27 books or equivalent for the versification)
-
B2 Gospel Harmony
-
B3 OT - portions
-
B4 New Testament Portions;
-
B01-99 individual book using TWO hexadecimal 'file number' listed in USFM spec;
-
B100-B999 sequential Scripture works prepared for publication in order. i.e. commentary volumes, etc. TTT - Translation trademark name (as in NIV, KJV, etc.) Where the work is complete and was published without a trade name, the editor's last name should be used. 1111 - Year of original publication of the version present on this repository. KJV1611 represents a blackletter presentation with original spellings. KJV1769 represents Blaney's published work. [LLL] - License [ PD or pd - public domain; R - restricted license similar to 'all rights reserved.'; CC - creative commons modifiable license.; NC - creative commons 'no changes' license. ] SSS - License holder or reference copy publisher. 2222 - year of the major release of the digital source text.
I also plan to have many more works present, including multiple languages. I've looked at uploading some spanish and Albanian works, but I haven't done so because I haven't figured out how to group projects on GiHhub. I also don't see a 'sort' button. Any ideas?
DavidHaslam
Suggest rename the USFM files to include the three letter book abbreviations as per the USFM User Reference.