Remove file sequence and prefix options from translate.py

[Copilot]

The --src-prefix, --trg-prefix, --start-seq, and --end-seq arguments in translate.py supported batch translation of sequentially-numbered files — functionality no longer used in production.

Removed

• --src-prefix, --trg-prefix, --start-seq, --end-seq CLI arguments from main()
• TranslationTask.translate_text_files() method and all call sites
• Corresponding src_prefix branch in experiment.py's translate() dispatch logic
• Unused import time (was only used in translate_text_files)

Updated

• --save-confidences help text: removed reference to .txt sequence file confidences
• Final else error messages in both translate.py and experiment.py: removed mention of "file prefix"

---

This change is 

[benjaminking]

I believe that the coding agent has removed all of the material related to file sequences and prefixes from the code base. I have verified that tests pass and other modes of translation are unaffected.

[benjaminking]

I also had to revert a recent change that produced an error when there was a mismatch between tokenizer sizes back to being a warning. The experiment smoke test uses Huggingface's tiny_random_nllb model, but still tokenizes the text with the full NLLB's tokenizer (in order to test as many SILNLP code paths as possible). And unfortunately the dimensions between these two do not match. I explored a few different ways to address this:

1. Using tiny_random_nllb's tokenizer, but this tokenizer has no tokens.
2. Create a local copy of the tiny_random_nllb and modify it to have the vocabulary size that matches tiny_random_nllb. A big downside to this approach is that it would require introducing some new code paths to hugging_face_config.py to have a third potential model prefix and tokenizer. Then the tests would no longer be covering the NLLB-specific code paths.
3. Perform a major refactoring that would allow us to inject the tokenizer that we want to use.
4. Revert the dimension mismatch error to a warning

I ended up going with option 4, since it seemed like it would have a relatively small impact on production use-cases, but would allow tests to have broader coverage without much development effort. In the long term, I think option 3 is probably best. In fact, I'll add a comment to the line with the warning to mention that we could have it be an error one we do the right refactorization.

[mshannon-sil]

I think converting it to a warning for now given the circumstances with testing is fine.

@mshannon-sil made 1 comment.
Reviewable status: 0 of 3 files reviewed, all discussions resolved (waiting on benjaminking).