As a translator, when I switch check apps I want to be ensured that something is happening behind the scenes rather than an empty loading bar so I have more confidence that the app is working.

Okay to fix with the "hacky" solution of brief pauses while loading to let UI render

As a developer, I want a centralized place to store my authentication tokens, so that I may have easy setup.

As a translator I want to see the morphology along side the short definitions of greek words so that I can better understand what greek words mean before I decide on a translation for my target language.

Many times when opening an app for a project the popup for progress shows but stays blank.

As a translator I want a faster interface so I can have more confidence in my control over translation core and the overall stability in the app.

Sometimes tC wants to lag really hard on the 0.1.1 build (tested on mac and windows). Luckily for us Facebook has provided some wonderful performance tools for React that you can get some more information on here.

The best thing we can do is isolate what is causing the slowdown across the board so we know what it is that we need to fix.

Please connect this repo at https://reviewable.io/repositories so that all PRs get linked to reviews. Thanks!

When getting my own project from D43, I can work on the checking and when I try to sync I get this:

My project has this in the .git/config:

[remote "origin"]
    url = https://git.door43.org/klappy/ilo_luk_text_ulb.git

Input from demos has asked us to use the highlighter looking way of rendering the view for showing what text is highlighted.

This does not mean to change the way text is selected. That can and/or will be a different issue.

As a translator of a language that is read from right to left I want my target language to be displayed in a way that I can read so I can translate more efficiently

As a checker I only need to see the context that is important to my check therefore I would rather have only one chapter load at a time in the tpane rather than an unresponsive interface so that I can still perform my check.

This is a controversial trade off that is bound to change in future iterations of tC. For now the tpane will just load the current chapter you are working in but there are cases where this would not provide enough context.

Some ideas tossed around were:

• Load in the first 20 verses of the next chapter and the last 20 verses of the previous chapter to catch the fringe cases where context needs to carry in between chapters
• Load the previous chapter and the next chapter would give all the context you would ever need and catch the fringe cases; There is the question of how expensive could this method get if you are working in a book with a few particularly long chapters
• Just load the current, previous, and next chunk; after all weren't chunks designed to provide you with all the context we need?

The tricky line to draw here is how much context will people need and that is not always up to us to decide. I would love some more input on this issue.

We should be able to export a single USFM file per Book and/or chapter. Import should be able to handle USFM files at Book level. Our exports should be importable as well. Imports should maintain usfm tags and not lose them and be there when saved and exported.

As an arabic translator I want to be able to check the Van Dykes new testament for accuracy so that I can have more confidence in the translation.

We're going to have to create a system, similar to what Atom has for compiling non vanilla JavaScript Modules.

The best way to do this, from what I read, is to have a location in disc storage where modules are compiled to, and to use that almost like a cache of compiled modules.

Now the only real issue I'm having with this is finding a way to compile an entire directory without using a node process, aka a hidden command line. Now if @klappy thinks it's okay to do so, then I can go ahead with it. Otherwise this will take some research.

• Ensure all data saves and reloads properly
• Complete Checking Interface
• Refine UI/UX
• Complete Reporting

As a user I want the report to be usable so that I can easily see what has been performed and needs to be changed.

Refine Reports for maximizing screen real estate. The current report page is difficult to understand what we're looking at.

We could use some of the same look and feel for the upcoming "changes app": #42

As a translation core developer I want to have diagrams describing the modular architecture of translation core as well as the different kinds of abstractions implemented in the API so that I have a better idea of how to write my modules.

As a user I want to have OT resources so that I can check my OT translations.

• Hebrew OT instead of Greek NT showing in T-Pane
• RTL displaying Hebrew
• Hebrew Lexicon

Closing app and opening again, looks blank but can simply choose an app and it opens without reopening a project. Progress does not load and makes the app look frozen.
This also happens when I refresh the screen.
I am also logged out.

On a mac, I can't use cmd+q or find a menu item to quit the app.

As a user I want to review all proposed changes and apply approved changes to each verse so that I can edit the translation and not leave tC.

Here's a rough mockup of the direction we're headed:

When a project and app is not currently open and showing, we should show recent projects and apps, so that you click once, and it opens the check up directly.

Instead of recent projects, we could show a list of projects in the "~/translationCore" folder.

• Written guide / tutorial would be helpful

As a dev I want to know what the name of the file I actually need is called so that my dev environment works.

If a user is connected to the internet, opens the app then disconnects, and loads an app they will be stuck in the loading screen and have to restart.
...if there are more errors you guys find we can make an epic.

As a developer I want to manage apps/modules in separate repos so that we can optimize development life cycles.

The topic of removing modules/apps from the tC codebase and each module/app being in its own repo has come up quite a few times when exploring this with other development teams.

Here are my thoughts so far:

• tC has no apps/modules in the code base.
• Each tC app has its own repo and lifecycle.
• We finalize tC API spec 1.0 and don't make any breaking changes to the API.
• Each app needs to define which API spec version that is being used for compatibility checks.
• We allow adding of tC apps just like adding a project, by git URL or release URL from github.
• We can ship tC with links to approved tC apps that can be downloaded with a click.
• Eventually add a way to browse and search for tC apps.

Decisions need to be made:

• Do we bundle any with the builds? Yes.
• Ensure that offline users have a way to get apps.

As a translationCore Checking Tool Developer, I want to have updated documentation for building Checking Tools, so that I can confidently develop.

Assess and collaborate with team building translationManager.

This Epic should include tasks/user stories for making the setup of tC much easier and simpler for new developers.

The current process is very cumbersome and challenging.

Mac OSX Instructions (Needs updating)

• Install X-Code
• Install Node.js
• Clone Repo (or Fork if not internal team)
• Pull latest develop branch
• sudo npm install -g electron
• Run application with electron .

Instructions for contributions

• Let the team know what you are working on
• Create feature branch
• Develop
• Commit early and often
• Ensure your code works. Test, Test, Test
• Push your branch
• Submit PR
• Rinse, Repeat, ..., Profit.

As a checker I want a menu that feels responsive so that when I make changes I know what I change is reflected on the actual data that I am manipulating.

When any state in the main view changes the re-render is so massive that it really slows down the view as a whole. To combat this we can minimize what is actually re-rendered when any of these states are changed so that the changes are less expensive

Long term it may be more beneficial to look into where we are using unnecessary states as well. There are certain on hover states in some components floating around in the main view that serve little to no purpose (other than styling, but there are plenty of ways to do that without state).

Many times loading reports can take a long time and feels like it didn't work and makes the user feel compelled to keep clicking and sometimes giving up.

Builds are crucial for non-developers, including demos, QA and field testing.

As a translation core developer I want to know why an empty .auth file still allows me to pull data from git/gogs so that I know if I can start working towards removing it completely.