Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Project Level/Multiple Books/Bundle #1991

Open
12 tasks
benjore opened this issue Jun 28, 2017 · 5 comments
Open
12 tasks

Project Level/Multiple Books/Bundle #1991

benjore opened this issue Jun 28, 2017 · 5 comments

Comments

@benjore
Copy link

benjore commented Jun 28, 2017

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

image

image

image

image

image

image

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
Copy link

RoyalSix commented Jul 17, 2017

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

@jag3773 jag3773 changed the title Ability to set the range for the check (e.g. book, NT, OT, full Bible) Project Level/Multiple Books Nov 14, 2017
@mannycolon
Copy link
Contributor

mannycolon commented Apr 11, 2018

  • 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.

bitmoji

@RoyalSix
Copy link

RoyalSix commented Apr 12, 2018

  • 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
Copy link
Author

benjore commented May 20, 2019

Contact Jesse to get format specs.

@benjore benjore changed the title Project Level/Multiple Books Project Level/Multiple Books/Bundle Jul 22, 2019
@benjore
Copy link
Author

benjore commented Jul 22, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants