Translation Source Organization

[mandolyte]

Currently, the Account Settings page does not prompt for a source for translations.

Concept:

• Add (and require) a prompt for the org from which the translation work will be done
• When user opens, say, Titus Literal, then two windows should open:
  • the source literal text
  • the target literal text
• If the target text does not exist, then a template should be opened to give them a place to start

Notes:

1. This implies that the windows will always be paired.
2. It implies that users cannot start without the source text - it must exist. They could not, for example, attempt translation from a paper copy of the source.

@birchamp After the call today, this need occurred to me. Might be overly restrictive... thoughts?

[mandolyte]

Branch Management

Overview and Definitions

In translation scenarios, there is always a source and target, a "from" language text and a "to" language text.

Even when a translator is simply reviewing or editing their own work, there is also a source and target. The source will be the work-in-progress in the master branch and the target will be the updates in their user branch. I call this the "editor" scenario.

Both source and target work occur in organizations and in a language and for a resource type. Importantly, the work exists in a repo, which equates to an organization, language, and resource type.

For an editor, there is only a single repo involved. They are updating content in a repo, not translating it.

For a translator, two repos are involved. One is the source repo; and the other is the target repo. The source repo is view-only. The target repo will receive updates made by the translators.

Editor Scenario

In this scenario, a single repo is involved.

Source: content is read from the master branch. This is on-going work-in-progress that has been approved, but not yet released (unless no updates have been made since the last release).

Target: content is read from editor's user branch. If it doesn't exist yet, it is read from the master branch. If any changes are saved, a user branch will be created if it doesn't exist and the changes saved into their branch.

Translator Scenario

In this scenario, two repos are involved.

Source: content is read from the source organization, language, and resource type, which equates to a repo in DCS. This is view only access. The content will come from the latest release for that repo; it will not from from the source repo's master branch (which is work in progress).

Target: content is read from target organization, language, and resource type, which equates to a (different) repo in DCS. In that repo, it is read from the translator's user branch.

• If the translator does not have a user branch yet, it will be read from the target master branch.
• If the content does not exist yet in the master branch (indicating that this is new translation work), then it will come from the source's latest released. (see note 1)
• Regardless of where the content for the target is obtained, once changes are made and saved, they will be saved to translator's user branch in the target repo.

Notes

1. A translator may wish to 'stick' with a released version of the source during a work effort. This would require persisting this preference somewhere in DCS. Since the translator may use different computers, it cannot be reliably stored locally. At this time, there is no solution proposed to store preferences in DCS. Thus in the above description, the source is said to come from the latest released.

[abelpz]

@mandolyte about:

At the moment no solution has been proposed to store the preferences in the DCS.

I always thought that the "source" property of the manifest.yml could work for that, that is, we could define which version we should use as source in the repo manifest.

This is a scenario that has happened to us:

• We start translating using a version of a resource as source.
• While we are working, there is a new released version of that source.
• When we finish, without realizing it, we have worked using two different versions as sources.
• When we are publishing our translation, it is not clear which version we should declare in the manifest that we have used as source.

Since, once we finish the draft it is reviewed by academics, I think it is not a big problem in terms of the quality of the translation, but it has confused me when I needed to state which was our source for the translation.

[abelpz]

I think if the software reads the manifest it already knows which released version it should try to load first as the source.

Then we should be able to change the source if necessary using some drop down select input and that preference should be stored in the browser, but there should be a button or some way to save that change in the manifest if we decide that's the one we're going to use.

Maybe this should be a gA concern, but I see this as something that could be handy to have in the application.

[mandolyte]

@abelpz I have contended that the manifest cannot serve this role because it represents data for the entire repo. Source versions should be associated with individual files.

Consider this scenario I described some time ago in Zulip: https://unfoldingword.zulipchat.com/#narrow/stream/207526-Tools---UR/topic/On.20Versioning/near/295839989

Possibly, the source version could be stored in the projects section. But there is also a risk of multiple updates to the manifest by a larger team that could lose data. You might minimize the chances of data loss by re-accessing the manifest just before you update to see it has changed since you updated it yourself. But this is no guarantee that another user on a different computer is doing the same thing. One of your changes will be lost.

[birchamp]

So I think the manifest could still be used. The source version would be the default version to open. If the user chooses to see a different version for a particular book that can be stored within the app's settings. gE already stores layout and book selection. It should be clear to the user that this isn't the default version, like the version number is in red or has a yield sign beside it.

If a team wanted to change the default source an admin could do that in gA. Finally if we have a call for versions per book we already list the books in the manifest. It wouldn't break anything to later add a source version for each book.