# data[].attributes.body
Checking process:

1. Checking for complete chapters - check each chapter in the book to make sure that each chapter is COMPLETE (starting and ending with the correct verses, according to the english BSB translation)

2. Checking for alignment - check to make sure the alignment is correct across the three languages is accurate by checking one verse in the beginning of the chapter, one verse in the middle of the chapter, and one at the end of the chapter. You will check across the English, Portuguese, Aramaic, and Hebrew/Greek to make sure the verses start and end where they should.

3. Upload the "checked' version to Google drive in appropriate folder with correct notation. (ie "40N_mat_1mul_ckd.csv")

4. UPDATE THE SPREADSHEET WITH NAME, DATE, AND UPDATED STATUS

# data[].attributes.body
1. Locate the File on Google Drive:
Go to the Google Drive and find a file whose name ends with "_mul" (e.g., 1O_gen_1_mul.txt).

2. Download the File:
Download the file to your computer and open it.

3. Check for Consistency and Completeness:
Perform the following checks:

a) Verify References: Ensure the reference numbers (book, chapter, and sentence) are correct according to the text. Correct any errors.

b) Check for Missing or Repeated Content: Ensure no verses or sentences are missing or repeated. Correct as needed.

c) Compare Translations: Read the text in all three languages to verify that the translations align. Use an interlinear Bible to assist with this comparison.

Here is the link to the interlinear Bible: Interlinear Bible.

4. Rename the File:
When your checks are complete, update the file name by adding "_chk" at the end to indicate it has been checked.
Example: 1O_gen_1_mul_chk.txt

5. Save in the Correct Format:
Save the file as plain text with UTF-8 encoding.

6. Upload the File Back to Google Drive:
Upload the updated file to the proper folder in Google Drive.

# data[].attributes.body
Narrative Variety

Genesis (OT) differs from Mark (NT) in style and time period, giving you broad coverage of narrative forms.

Poetic Text

Psalms contain parallelism, metaphors, emotional language—very different from narrative or didactic text.

Prophetic/Didactic

Jonah or Isaiah for prophecy, plus James for an epistolary, theological style.

This entire set might total around 1,000–1,100 verses and is robust enough to test a variety of morphological, syntactic, and semantic issues.

~1,000 verses is large enough to be representative, but not overwhelming for a pilot project.

Genesis 1–3

Creation story (narrative + dialogues). ~80 verses.

Selected Psalms: Poetry, varied themes. (e.g., Psalms 1, 19, 23, 51, 139) . ~5 psalms = 60–80 verses total.

Short prophecy narrative. Jonah (all 4 chapters) ~48 verses.

Mark (16 chapters, ~678 verses)

A full gospel for a comprehensive narrative sample.

If that’s too long, use only Mark 1–4 or Mark 1–8 for half the gospel (~280–400 verses).

Concise epistle with didactic/ethical focus. James (5 chapters, ~108 verses)

# data[].attributes.body
The steps to “prepare the environment” revolve around installing:

GPU drivers

Python + conda or venv

PyTorch (or TensorFlow, but PyTorch is recommended)

Fairseq or Hugging Face for NLLB-based fine-tuning

Then validate the GPU usage with a small test. Once that’s stable, you can proceed to your actual biblical data.

Check the step-by-step guide below:

# data[].attributes.body
1. Access the GPT Tool:
Use the following link to access our custom GPT for preparing multilingual databases of the biblical text:
Ready Vessels Interlinear GPT

2. Choose the Book and Chapter:
Enter the name of the book and chapter you want to work on in the GPT tool.

3. Wait for the Output:
The GPT will divide the text verse by verse or sentence by sentence.

4. Handle Incomplete Outputs:
If the GPT does not provide the entire chapter in one output, ask it to continue until the chapter is fully provided.

5. Copy the Biblical Text:
Copy the output to a new document on your computer.
Important: Ensure the document contains only the biblical text—do not include your conversation with the GPT.

6. Name the File Properly:
Use the following naming format:

1O_gen_1_mul.txt

1: Number of the book in the Bible.

O: for Old testament or N: for New Testament.

gen: First three letters of the book name.

1: Chapter number.

mul: Indicates multilingual.

.txt: File extension.

7. Save with Correct Encoding:
Save the file as plain text with UTF-8 encoding.

8. Upload to Google Drive:
Upload the finalized file back to its designated location in Google Drive.

# data[].attributes.attachment_link.title
Jornada Kamayurá (1966, INCE) : Instituto Nacional de Cinema Educativo : Free Download, Borrow, and Streaming : Internet Archive

# data[].attributes.attachment_link.description
Sinopse: Na Lagoa Ipavu, na região do Alto Xingu, vivem os índios da tribo Kamayurá, falantes do tupi. Aspectos da vida dos Kamayurás. Pela manhã, homens…

# data[].attributes.body
Ryder Wishart

12:52 PM (2 hours ago)

to me

Hi Marcia,

I'm so glad to be an encouragement, and I pray God will help us continue to find the right people like this so we can be connected and serve together for his kingdom! We will keep you up to date about the app. We have another developer starting on it today as well, so we should be able to increase our speed!

As for the alignments, I don't think there is a specific dataset that has sentences aligned, though there are many with verses aligned, which could give you a good starting point.

Here is the link to the eBible corpus, where each file is a language code + bible version. They are all free to use, and it looks like there are several Portuguese versions. https://github.com/BibleNLP/ebible/tree/main/corpus

Each file is aligned to this verse reference file: https://github.com/BibleNLP/ebible/blob/main/metadata/vref.txt

So if you copy the entire content of multiple bible files (blank lines included) and paste it into a spreadsheet alongside the verses, then you will have all the bible verses aligned as a starting point that you can copy and paste to chatgpt. Then you would need a new spreadsheet with sentence-level IDs like you shared an example of.

Hopefully this is helpful!

God bless and talk soon,

Ryder

# data[].attributes.body
Leandro - one of the translators

# data[].attributes.attachment_link.description
Intro Release notes Documentation Download Citing Support Resources Download the current version of ELAN for your platform By downloading and using ELAN you agree to cite ELAN in any publication based on research in which ELAN has been used. You can cite a paper or cite as software, e.g. as follows: “ELAN (Version 6.9) [Computer software]. (2024). Nijmegen: Max Planck

# data[].attributes.body
Once a year, the Kai people have a ritual called Kuarup to remember and mourn their loved ones who have passed away. For several days, they dance and cry, thinking about the lives of the people they lost and grieving over death itself. They paint their faces with patterns that look like tears to show their sorrow. They make a totem for each person who died, put it in the middle of the village, and dance around it. It’s their way of hoping the Creator will forgive their mistakes and that one day, their loved ones will come back to life.

# data[].attributes.body
Hi everyone! Today we’ll have a slightly different schedule. We’ll meet at 10 to pray for the project and for the Kai people, and to listen to the Lord. After that, Jolinde, Haley, and Paulina can work on organizing the data, storage, communication flow model, workflow, etc. Feel free to take as much time as you need for that on Friday. Suzuki, Snezhi, Luciano, and I will meet to go over Ryder’s materials and make some decisions. The others are welcome to join either group or consider themselves dismissed for the week. Thank you so much, and see you tomorrow!

# data[].attributes.body
Karina had the good idea of asking Chat GPT to do the segmentation. I had not tought about it, but decide to try with the first chapter of Ruth. Check the link!

# data[].attributes.body
Meeting on Jan 9.

# data[].attributes.attachment_link.description
posalign_two-step.ipynb. GitHub Gist: instantly share code, notes, and snippets.

# data[].attributes.body
Here is a code repository with a LOT of high quality data. (you have to download it and unzip it and then look through the folders)

# data[].attributes.body
If budget is not a concern and the goal is to create the best fine-tuning environment with a focus on performance and learning for a non-technical team, here’s what I recommend:

Best Resources for Training

To ensure the process is efficient, user-friendly, and maximizes learning opportunities:

1. Use Hugging Face Transformers Library

• Why?

• Hugging Face offers an intuitive interface for working with models like NLLB and provides a rich ecosystem of tools for fine-tuning, evaluation, and deployment.

• Their cloud service, Hugging Face Spaces, allows training without worrying about local hardware.

• Features:

• Pre-trained models like NLLB-200 are already available.

• Easy-to-use APIs for tokenization, training, and evaluation.

• Visual tools like Datasets Viewer to explore and clean your data.

• Steps:

1. Upload your dataset to Hugging Face Datasets Hub.

2. Use their AutoTrain feature for fine-tuning (great for non-technical users).

2. Leverage Cloud GPU Services

• Recommended Providers:

1. Hugging Face Accelerate (seamlessly integrated with Hugging Face tools).

2. Google Cloud AI Platform (user-friendly and scalable).

3. AWS SageMaker (widely used in industry but slightly more complex).

• Suggested Hardware:

• NVIDIA A100 or V100 GPUs provide optimal performance for fine-tuning models like NLLB-200 (especially larger versions like 1.3B or 3.3B).

• Advantages for Teams:

• Cloud environments abstract hardware complexity, letting your team focus on the process and learning.

3. Tools for Non-Technical Learning

• Use tools and platforms that abstract complexity but still allow experimentation and interaction with the model and data:

a. Google Colab Pro or Pro+:

• Provides a familiar, notebook-style interface.

• Built-in GPUs (T4, V100, or A100) for efficient training.

• Easy to collaborate and share with team members.

b. Weights & Biases (W&B):

• Tracks training progress visually (e.g., accuracy, loss, BLEU scores).

• Simplifies understanding of how hyperparameters and dataset size affect performance.

c. Hugging Face AutoTrain:

• Allows your team to fine-tune models without coding.

• Upload your dataset, select the pre-trained model, and let the platform handle the training.

Better Learning Experience for Your Team

1. Interactive Tutorials:

• Use Hugging Face Course (free and beginner-friendly):

• Covers training, fine-tuning, and deployment.

• Includes practical examples with datasets.

2. Visualization and Monitoring:

• Set up Weights & Biases (W&B) to visualize:

• Training loss, validation loss, BLEU scores.

• Tokenized input/output examples during training.

3. Data Exploration:

• Clean and explore the dataset using:

• Hugging Face Dataset Viewer.

• Tools like Pandas in Python for quick edits.

4. Hands-On Collaboration:

• Divide tasks like dataset preparation, model configuration, and evaluation across team members to promote learning.

5. Focus on Evaluation:

• Use SacreBLEU and ROUGE metrics for assessing translation quality.

• Have team members manually review and compare outputs to ground truths.

Proposed Training Environment

To balance learning opportunities with performance:

1. Platform: Hugging Face Accelerate (or AutoTrain for ease).

2. Hardware: Cloud GPUs (e.g., A100).

3. Data: CSV with English and Portuguese aligned.

4. Visualization: Use Weights & Biases for real-time insights.

Advantages of This Setup

1. Scalable Hardware:

• Cloud GPUs like A100 will fine-tune efficiently, even for larger datasets or models.

2. User-Friendly Tools:

• Hugging Face and W&B simplify the technical workflow for non-experts.

3. Collaborative Learning:

• Interactive platforms like Google Colab encourage team participation.

4. Professional-Grade Outputs:

• Fine-tuning NLLB-200 or larger models will produce high-quality translations.

Step-by-Step Implementation

1. Upload Dataset:

• Convert your CSV to TSV/JSON and upload to Hugging Face Datasets.

2. Choose a Training Method:

• Use Hugging Face AutoTrain for simplicity or create a script using the Hugging Face Transformers library.

3. Train the Model:

• Configure your training run (epochs, batch size, learning rate) using either:

• Hugging Face Accelerate for customizable training.

• AutoTrain for a no-code approach.

4. Track Progress:

• Visualize metrics (loss, BLEU, ROUGE) in real-time using Weights & Biases.

5. Evaluate:

• Test translations on unseen data and compare with the team.

Estimated Cost

For NLLB-200-distilled-600M:

• Cloud GPU (A100): ~$1.50–$2.50/hour.

• Training Time: ~2–4 hours for fine-tuning.

Total: ~$5–$10 per session, scalable depending on dataset size and model.

Conclusion

For the best balance of performance and team learning:

• Use Hugging Face AutoTrain or Transformers library.

• Choose Google Colab Pro or a cloud GPU for hardware.

• Track and evaluate progress with Weights & Biases.

# data[].attributes.body
Kakatsa, the other translator

# data[].attributes.body
Our team visiting the tribe

# data[].attributes.body
1. Google Colab: Log in, open a new notebook.

2. Import Libraries: !pip install transformers sentence piece datasets.

3. Upload CSV: Put your CSV files in Colab or Google Drive.

4. Create Parallel Files: For each language pair, create source and target text files with matched lines.

5. Download NLLB: model = AutoModelForSeq2SeqLM.from_pretrained(...).

6. Tokenize: Insert the correct language tag for your source text (e.g., <2heb>) and set the target tag (e.g., <2sat>).

7. Fine-Tune: Run the training process using either Hugging Face’s Trainer or another library.

8. Check Progress: Look at validation scores or BLEU-like scores.

9. Test: Translate some new verses that were not in training. Share them with bilingual or Sateré speakers for review.

10. Refine: If you see mistakes, gather corrections and adjust your data or model settings, and retrain if needed.

# data[].attributes.body
Install PyTorch (GPU-Enabled)

Once in the environment, install PyTorch with GPU support. For example (using pip):

bash

Copy

pip install torch torchvision torchaudio --extra-index-url https://download.pytorch.org/whl/cu118

Adjust the cu118 if you want a different CUDA version (like cu117 or cu121) depending on your driver.

# data[].attributes.headline
Converting documents into Plain Text files with UTF-8 encoding

# data[].attributes.subject
Converting documents into Plain Text files with UTF-8 encoding

# data[].attributes.body
Yes, you can easily convert a Word document into a plain text file using different methods, depending on the tools you prefer to use. Below are clear instructions for converting a Word document to plain text.

1. Using Microsoft Word

1. Open the Word Document:

• Open the .doc or .docx file in Microsoft Word.

2. Save as Plain Text:

• Go to File → Save As.

• Choose a location to save the file.

• In the “Save as type” dropdown menu, select Plain Text (*.txt).

• Click Save.

3. Encoding Options (if prompted):

• Choose UTF-8 encoding to ensure all characters, including special ones (e.g., Greek or accented letters), are preserved.

• Click OK.

2. Using Google Docs

1. Upload the Document to Google Docs:

• Open Google Drive and upload your Word file.

• Right-click the uploaded file and choose Open with Google Docs.

2. Download as Plain Text:

• In Google Docs, go to File → Download → Plain Text (.txt).

• Save the .txt file to your computer.

3. Using LibreOffice or OpenOffice

1. Open the Word Document:

• Open the .doc or .docx file in LibreOffice Writer or OpenOffice Writer.

2. Export as Plain Text:

• Go to File → Save As (or Export in some versions).

• In the “Save as type” dropdown menu, choose Text (.txt).

• Choose UTF-8 encoding for compatibility.

• Click Save.

4. Using Online Converters

1. Choose an Online Tool:

• Visit an online Word-to-Text converter, such as Convertio or Online-Convert.

2. Upload the Word Document:

• Upload your .doc or .docx file to the platform.

3. Download the Plain Text File:

• Once the conversion is complete, download the .txt file.

5. Using Python (Automated Conversion)

If you prefer automation and have Python installed, you can convert Word documents to plain text using the python-docx library.

Install python-docx:

pip install python-docx

Python Script:

from docx import Document

# Paths to input and output files

input_file = "your_document.docx"  # Replace with your Word file path

output_file = "output_text.txt"    # Replace with desired plain text file path

# Open the Word document and extract text

doc = Document(input_file)

with open(output_file, "w", encoding="utf-8") as

# data[].attributes.body
Using the GPT Key Terms Organizer

1. Create the Database:

Use the GPT Key Terms Organizer to build a database of biblical terms for tagging datasets or feeding the AI model.

Simply type the term you want to add in English or Portuguese.

Press "Enter" after each term. The list will automatically update, numbering the terms and re-alphabetizing them.

2. Save Your Updated List:

At the end of your session, save the updated list as a plain text file in the appropriate folder in the Kai Project Google Drive.

Steps for Managing Your GPT’s List of Terms

1. Create a Text File in Google Drive:

Open Google Drive in your browser.

Create a new file (Google Docs or Google Sheets) or upload an existing text file.

Name the file, e.g., “MyGPTList.txt,” to easily identify it.

2. Copy the Updated List:

When GPT provides the updated list, select all the text and copy it.

Paste it into your “MyGPTList.txt” file (or the document you created).

3. Save the File:

Ensure you save changes in Google Drive before closing.

The file now contains the most recent version of your GPT list.

4. Use the List in a New GPT Session:

Open “MyGPTList.txt” in Google Drive and copy the entire list of terms.

Start a new GPT session. Paste the list at the beginning of the conversation, along with a short note:
“Use the list below as the updated dictionary, and append new terms to it.”

5. Update and Save the List Again:

After GPT updates the list, copy the revised version.

Paste it back into “MyGPTList.txt,” replacing the old version.

Save the file in Google Drive so it’s ready for the next session.

By following these steps, you ensure your custom GPT always starts with the latest version of your biblical terms list.

# data[].attributes.attachment_link.description
Creates and updates a multilingual list of key terms in Plain Text Format

# data[].attributes.body
Windows 11 can handle deep-learning frameworks (PyTorch, TensorFlow, etc.) just fine nowadays.

Linux is still more common in research, but if you prefer Windows, that’s okay—just be sure to follow Windows-specific instructions for GPU drivers and CUDA.

2.1. Optional: WSL or Dual-Boot

Some developers install Windows Subsystem for Linux (WSL) or do a dual-boot with Ubuntu for a more “native” Linux environment.

This is optional; if you’re comfortable in Windows, you can do everything directly on Windows with the correct drivers.

# data[].attributes.headline
Where do I find the files in the Google Drive?

# data[].attributes.subject
Where do I find the files in the Google Drive?

# data[].attributes.body
The first folder is for Old Testament and the second folder is for New Testament. Find yoyr file and download it to your computer.

# data[].attributes.attachment_caption
Paulina showing where to save your work on the Google Drive. The link where all files are stored is here: 

# data[].attributes.body
https://drive.google.com/drive/folders/1Y1XOgVDCKs0oe5uXZW9UhhFl05AgxkjE?usp=sharing

1. Do Not Edit Files Directly in Google Drive: Do not work on files directly within Google Drive to prevent issues or errors.

2. Download the File: Always download the file to your computer before making any changes.

3. Edit Locally: Make the necessary edits or changes on your computer.

4. Rename the File: Update the name of the file to reflect your changes or edits (_mul, _ chk, or _tgd), according to your task.

5. Save in the Correct Format: Save the file as plain text with UTF-8 encoding.

6. Upload the File Back to Google Drive: After saving, upload the updated file back to its original location in Google Drive.

# data[].attributes.body
1. Locate the File on Google Drive:
Go to Google Drive and find a file whose name ends with "_chk" (e.g., 1_gen_1_mul_chk.txt).

2. Download the File:
Download the file to your computer.

3. Tag the File:

Use the list of key terms and proper names to add the appropriate tags to the text.

Carefully ensure all key terms and proper names are correctly tagged.

4. Rename the File:
When tagging is complete, update the file name by adding "_tgd" at the end to indicate it has been tagged.

Example: 1_gen_1_mul_chk_tgd.txt

5. Save with the Correct Encoding:
Save the file as plain text with UTF-8 encoding.

6. Upload the File to Google Drive:
Upload the updated file to the correct folder in Google Drive.

4o

# data[].attributes.body
If you want, you can use the interlinear Bible to check Genesis 1. It will help with identifying sentence boundaries in a language that you don't know.

# data[].attributes.attachment_link.title
Genesis 1:1 Interlinear: In the beginning of God's preparing the heavens and the earth --

# data[].attributes.body
1. Check GPU:

python

Copy

import torch print(torch.cuda.is_available()) # should print True print(torch.cuda.get_device_name(0))

Confirm it sees your RTX 4090.

2. Optional: Download a small model (like facebook/nllb-200-distilled-600M) and run a quick forward pass to ensure everything works.

5. Next Steps for Fine-Tuning

1. Data Preparation

Organize your parallel data (Hebrew/Greek/Aramaic ↔ LRL or Portuguese → LRL).

Clean and align the verses, split into train/validation/test.

2. Preprocessing

For Fairseq: fairseq-preprocess with language codes or scripts for your new language.

For Hugging Face: create tokenized datasets with a custom tokenizer or the pre-existing NLLB tokenizer.

3. Training Script

For Fairseq: fairseq-train data-bin ... --arch transformer ... --finetune-from-model nllb_checkpoint.pt

For Hugging Face: set up a Trainer or Seq2SeqTrainer with your model, data, training args.

4. Monitor GPU Usage

Start with smaller batch sizes if memory usage is too high. 24GB VRAM is good but large models can still push it.

# data[].attributes.body
Hugging Face Transformers or Fairseq

If you want NLLB via Fairseq:

1. pip install fairseq

2. Clone the repository if you need advanced scripts:

bash

Copy

git clone https://github.com/facebookresearch/fairseq.git cd fairseq pip install --editable .

If you prefer Hugging Face Transformers:

1. pip install transformers==4.xx (latest version).

2. pip install sentencepiece for tokenization.

Any Additional Dependencies:

pip install sacrebleu or pip install evaluate for translation metrics.

# data[].attributes.body
1.1. System Components

1. CPU: Intel Core i9-14900KF

A top-tier CPU with plenty of cores/threads for data pre-processing.

2. GPU: NVIDIA RTX 4090 (24GB VRAM)

Excellent for large language model (LLM) fine-tuning. The 24GB VRAM is quite ample.

3. Motherboard: MSI PRO Z790-P WIFI

Suitable for DDR5, CPU, GPU, and has Wi-Fi 6E. Good for a robust build.

4. RAM: 32GB DDR5 6000MHz + potentially you mentioned “96 MB” or additional memory:

32GB system RAM is generally workable for many training tasks. If you have more (e.g., 64GB or 96GB total), that’s even better.

5. Storage: 2TB SSD + maybe an HDD

2TB SSD for fast I/O during training.

If you have a secondary HDD, that’s good for backups.

6. PSU & Cooling

1000W Gold PSU and an AIO liquid cooler for the CPU. This is great for stable, cool operation when the GPU/CPU are fully loaded.

Conclusion: This machine is powerful enough for NLLB fine-tuning or other large-ish model fine-tuning tasks. Many people do small or medium-scale training on a 4090 with success.

# data[].attributes.body
1. Project Overview

Ready Vessels is a multifaceted, multimodal project aiming to translate the Bible from its original languages (Biblical Hebrew, Koine Greek, Biblical Aramaic) into multiple low-resource languages (LRLs). From the outset, the project envisions more than just text: it plans to collect or align audio, images, and possibly video—gradually building toward a richer “human-like” language learning approach. However, the initial phase will be text-based for practical, step-by-step learning and pipeline development.

2. Goals

1. Establish a Multimodal-Ready Fine-Tuning Pipeline

Create a flexible workflow for fine-tuning large multilingual models (e.g., NLLB) that can incorporate various data types (text, audio, images) as they become available.

Start primarily with parallel text (biblical verses, minimal expansions, optional dictionary usage) to keep things straightforward, yet keep the framework open to integrating audio or other modalities.

2. Include Native-Language Materials

Beyond direct biblical translations, collect originally produced LRL stories, dialogues, proverbs, or sermons, interpreted into a pivot language.

Ensure the final translator outputs a culturally authentic style by learning from real native LRL discourse, not just adapted text from a foreign source.

3. Pilot with Sateré, Scale to Kai

Use Sateré first as a sounding board, where the project lead can verify translations. Develop, test, and refine the pipeline—covering text alignment, dictionary usage, potential minimal tagging strategies, etc.

Apply the same approach to Kai (oral-based language) and other LRLs that have minimal textual resources.

4. Domain Focus

Keep the additional (native) materials thematically tied to biblical or spiritual contexts—avoiding large domain mismatches. This ensures synergy with the biblical text domain.

3. Approach

3.1. Multimodal Vision from Day One

Project Definition

Although the initial pipeline is text-focused, all planning documents and data structures will be designed so that audio, images, or video can be integrated later.

Tools like ELAN may be used to align text with audio or video recordings of LRL stories/sermons.

Incremental Implementation

In the early phase, the model is fine-tuned on verse-level textual data.

As new data (audio, images) becomes available, separate or extended architectures (multi-encoder or speech-to-text) may be fine-tuned or adapted to produce a more “embodied” understanding.

3.2. Text Corpus & Parallel Alignment

Biblical Corpus

The entire Bible in English, Portuguese, and biblical languages (Hebrew, Greek, Aramaic).

Verses that also exist in LRL get aligned in a parallel table.

Native LRL Materials

Collect locally composed stories, proverbs, dialogues, or sermons in the LRL.

Interpret or translate them into a pivot language (e.g., Portuguese). This yields LRL → pivot data or pivot → LRL data, offering additional coverage of natural LRL usage.

3.3. Minimal Expansions & Optional Dictionary

Simplicity First

Keep expansions in the biblical verses minimal to ensure clean alignment.

Rely on a dictionary (for theological terms, proper names) at either inference or a post-processing step to ensure consistent translations.

Gradual Tagging

If needed, selectively tag top priority terms (e.g., “Spirit,” “Messiah,” “Jerusalem”) but avoid cluttering the entire dataset.

3.4. Fine-Tuning NLLB (or Similar) in Multiple Phases

1. Small “Test Runs”

Use partial subsets (e.g., a few NT books in Sateré) to confirm your scripts, alignment, dictionary usage, and hyperparameters.

2. Full Runs

Incorporate all aligned data: biblical text for languages that exist, plus the original LRL materials.

Evaluate with BLEU/chrF plus human checks (the project lead or native speakers).

3. Potential Multimodal Extension

Over time, gather audio or video data aligned via ELAN or other tools.

Adapt the model with a speech or multi-encoder approach, building on the text-based checkpoint.

4. Phases & Steps

1. Phase 1: Foundations & Pilot with Sateré

Gather Sateré NT or other biblical portions + original Sateré discourse (stories/sermons).

Align them with Portuguese/English. Set up minimal expansions, optional dictionary for key biblical terms.

Fine-tune NLLB in a text-based scenario, test multiple runs to refine approach.

Keep the project labeled as “multimodal,” acknowledging future addition of audio or images.

2. Phase 2: Expand to Kai

Transfer the refined pipeline to Kai, a mostly oral language.

Continue collecting original Kai recordings of biblical or related spiritual content, interpret them into pivot languages.

Possibly do initial steps to align audio or basic video segments with text.

3. Phase 3: Multimodal Integration

As resources grow, begin adding or linking time-coded audio (sermons, dramatizations, etc.) or illustrated Bible scenes.

Explore specialized multi-encoder or speech-to-text architecture to fully harness the additional modalities.

4. Phase 4: Scaling to More LRLs

Repeat the pipeline: clean text alignment, optional dictionary usage, minimal expansions, incorporating native texts, eventually moving to audio or images if feasible.

5. Summary

Ready Vessels is multimodal from the outset in its vision, while initially deploying a text-only pipeline for practical reasons.

Incorporating original LRL materials ensures the model’s output is culturally resonant, not just a direct “foreign text” style.

Gradual steps: pilot with Sateré, refine, then expand to Kai and other languages—always leaving room for future addition of audio/video alignment or advanced morphological approaches if the text-based approach hits domain or style limitations.

This plan ensures you develop a flexible, robust foundation for biblical domain translation that can later accommodate the “multimodal” dream—mirroring a more “human-like” way of language learning.

# data[].attributes.body
Record here your video-reactions about "How People Use Language", the OBT Handbook, or any other topic related to the session 5.