search

unfoldingWord / gateway-translate

A tool for editing and translating text in USFM markup
MIT License
2 stars 3 forks source link

USFM by URL #63

Closed mandolyte closed 1 year ago

mandolyte commented 2 years ago

USFM by URL

Goal: a translator will be able to view and/or edit USFM text obtained via URL.

There are three general use cases.

Use Case 1

The USFM text comes from DCS, but user does not have access to save the changes. For example, the Original Languages Greek and Hebrew texts, wherein the user, unless thay are a member of the unfoldingWord organization, will not be able to save any changes. This use case is expected to common for any translator who know Greek or Hebrew.

Use Case 2

The USFM text comes from DCS and the user has access to save the changes, since they are a member of the owning organization. This would be a common use case for a translator who wanted to refer to legacy texts stored on DCS. This would also be the use case for making changes to the Greek or Hebrew texts.

Use Case 3

The USFM text does not come from DCS. This use case might be of use to anyone who wished to use our tools. Since the edits could not be saved, gT will need to provide a download option for the edited text.

Note on Original Languages

Since Greek and Hebrew is anticipated to be common use case, gT should conside a built in way to obtain the original language texts.

Considerations and Constraints

  1. If a DCS text is from a "release" URL, then even if the user has edit rights, we should only permit edits to be done from URLs from the master branch.
  2. The book ID must be a valid one. (reference)
  3. For DCS texts, inspection of the URL will yield both an organization and a repo. These might be used to formulate the required doc set ID.
  4. For non-DCS texts, creation of the required doc set ID will take some thought.
  5. Since we cannot always determine the book ID from the URL, consider forcing the user to specify the book from the drop down list. If we wish to support apocryphal or other non-canonical texts, our drop down should contain all the books from the reference in item 2 above.
  6. By requiring the user to supply the book ID, then these texts will be able to participate in the linked card navigation and synchronization. (see issue 16)
superdav42 commented 2 years ago

@birchamp @mandolyte It'd be helpful to have an example of each kind of url we want to support for each case above.

mandolyte commented 2 years ago

@superdav42 @birchamp

Combined use case 1 and 2 - simpler approach

Perhaps a simpler approach is to change the dialog to include the org and repo. The org could default to that specified in the account settings. This would be an easy way for users to access book in repos that don't follow our naming standards.

And from there we could determine whether the user has write access to the repo. So this takes care of use cases 1 and 2.

If they have write access, we could have the save button. But if they don't we could replace it with a "download" button.

Example:

Possibly even provide a file picker instead of letting them type it.

Use case 3

For the pure URL approach we could just treat it as data they cannot save back to the original location. In this case, we'd show the download button instead of the save button.

mandolyte commented 2 years ago

@superdav42 almost forgot... Mark had a good idea, namely, get the book ID from the fetched USFM. This would be used as part of use case 3 in preceding post.

superdav42 commented 1 year ago

Since Greek and Hebrew is anticipated to be common use case, gT should conside a built in way to obtain the original language texts. Possibly even provide a file picker instead of letting them type it.

To solve both of these requirements, why not just add language as a drop down in the add scripture dialog? We could have original languages at the top of the list and the rest below.

We could add a check box to show all languages which would show even those repos that they are not members of.

mandolyte commented 1 year ago

How would you convert a language to a file to fetch in DCS?

Perhaps some Catalog Next query?

On Mon, Nov 7, 2022 at 7:06 PM David Stone @.***> wrote:

Since Greek and Hebrew is anticipated to be common use case, gT should conside a built in way to obtain the original language texts. Possibly even provide a file picker instead of letting them type it.

To solve both of these requirements, why not just add language as a drop down in the add scripture dialog? We could have original languages at the top of the list and the rest below.

We could add a check box to show all languages which would show even those repos that they are not members of.

— Reply to this email directly, view it on GitHub https://github.com/unfoldingWord/gateway-translate/issues/63#issuecomment-1306395541, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ2ZXPC53ZYPGTZSTVGPNLWHGKP5ANCNFSM6AAAAAARX77MHI . You are receiving this because you were mentioned.Message ID: @.***>

superdav42 commented 1 year ago

How would you convert a language to a file to fetch in DCS?

I was going to start with the same language list that's used in the account settings + Greek and Hebrew. This includes all the GW languages in languages.json.

Perhaps some Catalog Next query?

Querying catalog next would probably be best. I'm not sure how to do that but ideally we'd get a list of all bible text for a given org in catelog next. @richmahn Do you know such a query that could do this?

Here's what I have so far: image

mandolyte commented 1 year ago

Nothing like a picture to explain. Looks good!