Projects

What is a project?

We use a shared conception of a project, which is a lot like a package.json file in a web app. Scripture Burrito has specified a schema for a project manifest.

Example Folder Structure

folder-where-i-store-my-translation-project/
├── metadata.json
├── ingredients/
│   └── ...
├── .git/
└── .project/
    ├── index.json
    ├── resources/
    └── ...

folder-where-i-store-my-translation-project/

This folder is the top-level of the project. It's a folder (probably on your machine) where the entire project is stored.

metadata.json

This manifest makes your folder into a Scripture Burrito. It contains important metadata about your project, such as what languages you are translating to/from, who owns the project, license information, etc. It also includes a declaration of the project's "ingredients."

ingredients/

The ingredients folder contains all of the project content that should be bundled in the Scripture Burrito and tracked in source control. This includes your translation drafts, files contributed by the user, custom content, dictionaries, etc.

.git/

If you are using git, then your revision history will be contained in this hidden folder by default. If you are using some other source control manager, then you would put that content at this top level under some other kind of folder (you don't have to use git if you don't want to, or can't because you want fine-grained revision info on audio files, etc.).

.project/

This is a hidden folder we have introduced for storing content that is important for the translation project but should not be tracked in the project's source-control. For example, if you download resources from Unfolding Word vis DCS, you do not want to track these third-party resources or bundle them with your project's Scripture Burrito. Rather, each of these resources is stored under a resources/ folder, and the paths to the various downloaded resources are indicated in the index.json file.

.project/index.json

This index file is used to list downloaded resources with some metadata. The metadata includes the following:

  • ownerId - some kind of id for the organization in the source control, whether DCS or GitHub, etc. This is necessary because you may have two orgs both offering their own version of the English Translator's Notes, for example.

  • flavour - the scripture-burrito type of the resource (TODO: need to clarify types and subtypes here based on scripture burrito schema.)

  • language - the ISO-639-3 language code of the resource.

  • path - the path to the resource under the .project/resources/ folder.

  • retrievedAt - timestamp for when the file was last downloaded (TODO: ISO string timestamps?). If a user downloads a new copy of the same resource, this field differentiates versions. We can optionally prune older versions on the fly, if needed.

This index file allows you to quickly filter resources by language or organization, etc.

.project/resources/

The downloaded resources are stored here, and each resource path is appended a unique random string so that if you download another copy, you will always be able to know which one you are accessing. The path to each file, including the random string, is specified in the .project/index.json index. NOTE: Each downloaded resource is stored as a Scripture Burrito, that is, with a manifest.json and ingredients folder.

Initializing a new project

Codex will have a bundled Project Management extension that helps users initialize and manage new projects.

For example, for a "codex" project, which is not an official Scripture Burrito type (yet! ever?), you need a number of extension-based functionalities.

These functionalities could all exist in a single extension, as in the codex-editor extension, but you could also break functionality out into multiple atomic extensions.

What really matters is that we are able to associate a given type of translation project with the tools and extensions needed for translators to work on that project.

Last updated