Project Level/Multiple Books/Bundle

[benjore]

NOTE: The bundles need to upload projects according to the RC spec so that they can be automatically published without massive data massaging.

User Story

Possibly this includes adding support for a Project level scope which would include multiple books of the Bible in a specific translation.

Feedback from Ludhiana

"Book to entire Bible - As of now Translation Core is based on a book at a time. Would like to see if it is taken for full Bible at once. I mean, Once we have done the BT in one book then all those keys terms should be saved and if the same Key/Biblical terms are used again in another book then under the blue box where we explain the meaning of the Key / biblical words, all the words used for this in other books should come so user may find it easy to choose the words which was already been used. This will improve the consistency."

Mockup

Notes

• [ ] On Bundle export or upload to Door43 we need to use the combined USFM bundle format, as described in http://resource-container.readthedocs.io/en/latest/container_types.html#bundle-bundle and illustrated in https://git.door43.org/Door43/en_ulb .
• [ ] If a USFM bundle is imported, break all the individual projects out (so they can be opened individually) but also create a bundle with all of the projects.
• [ ] Naming Convention: (see https://git.door43.org/Door43/registry )
  • [ ] Create a "Title" field for the bundle (add to metadata)
  • [ ] The actual repo name is made of:
  • [ ] language code (taken from manifest)
  • [ ] three-letter code (free-form)
  • [ ] add tcbundle + two digit ascending e.g. 01 (example: sw_xyz_tcbundle_01, pt-br_udb_tcbundle_01, sw_xyz_tcbundle_02)
  • [ ] If the three-letter code is renamed, then the DCS repo will need to be renamed upon the next "upload to door43" (keep track of the DCS URL in the bundle manifest)
• [ ] Upload to Door43 - all projects are uploaded to their own repo. The bundle manifest (in a new repo) is also uploaded which references the different projects. The bundle manifest will have the usfm bundle (no checking data), checking data will reside in the individual repos.

Consider

• [ ] Import USFM bundles
  • [ ] Be able to handle book introduction USFM files as a part of a bundle (A0-FRT.usfm, or 00-FRT.usfm)

[RoyalSix]

For example reducers can't handle multiple book...

[mannycolon]

• [ ] Each bundle has its own manifest with all the projects information.
  • [ ] Include key to identify the repo is a tC bundle.
• [ ] Create a bundles folder in the user's translationCore folder.
• [ ] Uploading bundles to door43.
• [ ] Importing bundles from door43.
  • [ ] How to handle projects already loaded.
  • [ ] Reimporting projects from a bundle.
• [ ] Exporting USFM bundles.
• [ ] Exporting CSV bundles.
• [ ] App performance with the side menu & check switching.
  • [ ] Load chapters for the previous, current and next checks.
• [ ] Add support for multiple projects in the reducers
  • Multiple contexIds
  • Multiple indices (indexes)
• [ ] Add target Bibles to the resources reducer by book Id reference
• [ ] Tools progress for bundles.
• [ ] Support project validation for bundles.
  • Merge conflict check for bundle projects.
  • Missing verses check for bundle projects.
• [ ] Load translation helps when switching between books.

[RoyalSix]

• Need to have the same license
• CSV Export
  • Concat the checks
• Need to be able to import
• Delete bundle do not delete the projects
• Locking projects into one language
• Not re-reading chapter on each context ID change
  • See changeCurrentContextId

[benjore]

Contact Jesse to get format specs.

[benjore]

From Russ Perry: A feature request from Vipin at BCS. This may be unique to BCS because of their workflow in managing multiple GL projects, but you can take it into consideration if it might be applicable more broadly. Background: When each GL aligner completes several books, they export the USFM files with alignment data and email them to Vipin. Vipin forwards the files to another person who checks them. After the files are checked, and after he has collected files for several books and possibly several GLs, Vipin creates each project in his copy of tC, and then uploads the projects to DCS. Vipin's request is for tC to enable uploading projects for several books in a language as a batch. This would make the upload process more efficient for a project manager such as Vipin. Perhaps tC could present a list of projects for a language and then the user could check a checkbox for the ones to be uploaded, then clicking Upload does all of them. Another suggestion. Vipin requests that tC enable creating projects for several books in a language as a batch. The language name/code and identifier should be the same, although the filenames would be unique. Maybe tC could accept a folder name and create projects for each file in the folder.