Alignment Component

[mandolyte]

I'll post my thoughts on how this might work in a subsequent comment.

[mandolyte]

Goals and Assumptions

Goal: maximize re-usability of alignment component by minimizing its dependencies on its environment.

Assumptions:

• In the description below, I assume that the alignment component (AC) lives in its own page in gateway-translate which is a NextJs application. Being in its own page makes it easier to reason about.
• Let's also assume that the way to route to the aligner page is by selecting it in the sidebar navigation.

Workflow

After user logs in, opens a file, and (perhaps) edits it. Then they wish to align it.

1. In side navigation, click the alignment button
2. The app routes to the alignment page
3. The page shows a list of files that have been opened.
4. The user selects a book
5. The app retrieves the original language text for the selected book (if hasn't been retrieved already) and loads it into the PK cache (converting it to PERF along the way)
6. The app accesses the original language PERF for the selected book from the PK cache
7. The app accesses the edited PERF for the selected book from the PK cache
8. The app instantiates the alignment component with the two PERF files, plus a save function, the bookId, and the versification for the book.
9. Thus the component would look something like this:

   <Aligner 
      originalLanguage={olPerf} 
      content={editedPerf} 
      bookid={bookId}
      onSave={onSave}
      versification={vrs}
   />

10. The AC would then show, defaulting to chapter 1 verse 1.
11. In addition to the alignment area, the follow UI elements are needed:
    • chapter and verse navigation
    • a Cancel button: routes to main workspace without saving
    • a Save button: save the updated PERF to the PK cache
    • a Close button (which saves and routes to the main workspace)
12. Possibly, the cancel and close may need to fire functions provided by the app. In that case, they would be passed in similar to the "onSave" above.
13. Possibly, instead of passing in PERF, it may be desirable to pass in Epitelete instances

[mvahowe]

Ok, so chapter/verse (or whatever) navigation would be an aligner RC concern? I had imagined that the aligner RC would be given the chapter/verse context of the text editor. If not, it feels to me like the aligner is working in its own context and, in that case, it probably shouldn't be in the same page as the text editor.

It's really a question of workflow. I was imagining that people are editing a verse and then want to do a quick bit of aligning. (Or, they are aligning and realise that they need to make a change to the text, which is the tCore workflow.) In that case I think we should have shared bcv navigation for both text editor and alignment, and the user effectively swaps between two views of the bcv context.

Alternatively, if alignment is primarily a separate activity, it might make sense to do it somewhere far from the text editor. But even in that case, I think we'd want a way to jump from the text editor to align the thing that was being edited, or vice versa.

[mvahowe]

To

maximize re-usability of alignment component

the bcv context could potentially be more than a verse, eg a verse range, a chapter, a book...

[mandolyte]

@mvahowe thanks... I had never imagined that a translator would want to flip back and forth between translating and aligning. But then I'm not a translator... need some expert user input on that point. Keeping it separate has a lot advantages on the development side and for the robustness (way less complicated and prone to bugs). But I may have to concede the point.

In the workflow I described, the context would always be a verse or a verse range... i.e., it would be driven from how the target text was structured. And the Original Language side would need to show all the verses represented in the target range.

[larsgson]

I could imagine both approaches here above to be useful - depending on use cases, I guess... So maybe the question to @birchamp might be: Which approach has first priority for gT right now?

• Alignment by verse, or verse range as per @mvahowe here above
• or more of a full navigation (by book) aligner as per @mandolyte

And from my point of view, I actually do not really think that keeping it separate has much development side advantage (if any).