globalbibletools / gbt

https://interlinear.globalbibletools.com
15 stars 2 forks source link

select verse to translate #25

Closed arrocke closed 1 year ago

arrocke commented 1 year ago

acceptance criteria

Pertempto commented 1 year ago

Ideas from meeting

Pertempto commented 1 year ago

@arrocke I'm pretty sure there are sometimes discrepancies about verses per chapter and chapter numbering, depending on the translation? How do we want to handle that.

Pertempto commented 1 year ago

@arrocke I'm pretty sure there are sometimes discrepancies about verses per chapter and chapter numbering, depending on the translation? How do we want to handle that.

Maybe a question for @BethedenMinistries

arrocke commented 1 year ago

My two cents would be that we use the chapter and verse numbers as provided by Sheldon's data. That's the data introduced in #49. We can tackle other verse numberings if/when we integrate with translations that have differences.

Pertempto commented 1 year ago

@arrocke I'm trying to load the book terms JSON file from my verse selector component. Is using require an acceptable way to do this? Will it break anything with webpack?

  const { language } = useLayoutContext();
  const langCode = language?.code ?? 'en';
  const bookTerms = require(`../../assets/book-terms/${langCode}.json` );

  const { bookId, chapterNumber, verseNumber } = parseVerseId(verseId);
  const bookName = bookTerms[bookId - 1][0];
  const reference = `${bookName} ${chapterNumber}:${verseNumber}`;
Pertempto commented 1 year ago

Status Update

I've got the basic UI implemented, with a text box and two arrow buttons.
The textbox displays the current reference, and the previous/next buttons function well. They wrap from the end of one chapter to the beginning of the next, and from one book to the next.

image

All that is left is getting the text box to respond to input from the user. @arrocke How should we handle invalid inputs by the user in the text box?

Pertempto commented 1 year ago

I've got basic text input working. I designed it to be very permissible. For example, if the user inputs "John 4:230", it will take them to John 4:54 (the last verse of John 4). This way they at least get close to where they wanted to be, even if they had a typo.

Currently, an invalid input such as "tacos 4:23" will result in the verse selector being cleared, but no change in translation view. Is this good enough for the MVP? I feel like we could add error indicators later if we decided they were necessary.

arrocke commented 1 year ago

Nice work! This is looking good

I prefer to have these kinds of conversations on a PR, because I can code changes, and put comments on the code. So my personal preference is that once code is being written, conversation about implementation moves to the PR. I'm open to your ideas thought if think differently.

I'm trying to load the book terms JSON file from my verse selector component. Is using require an acceptable way to do this? Will it break anything with webpack?

The language here is the language being translated into, not the interface language. So to render the reference we want to use i18next and useTranslation. We can create a separate translation namespace called bible.json for all of the Bible specific strings. Then you can use t to convert the verse id in a reference in the language of the interface.

How should we handle invalid inputs by the user in the text box?

I agree that we can add error messages later. We are going to need a general approach to validation which I don't want to mess with right now.

I've got basic text input working. I designed it to be very permissible.

This is a good idea. In addition, the strings used for lookup should probably come from translation strings as well. i18next has methods to get translation strings that might be useful to build something that can parse a reference string in the interface language.

Pertempto commented 1 year ago

I prefer to have these kinds of conversations on a PR, because I can code changes, and put comments on the code. So my personal preference is that once code is being written, conversation about implementation moves to the PR. I'm open to your ideas thought if think differently.

Great point, I'll go ahead and create the draft PR.