We have a XOJO app that goes back 11 years. It is a translation editing tool. The main usage paradigm is to have a document that is split up into separate units, which for our configuration, are basically sentences. As a user, I see a table with source text in one column, target text in another. I click on a line in that table (or keyboard navigate, etc.). When I do that, a textarea on the left is populated with the source sentence (this text area represents maybe 5-10% of the total screen area). A textarea on the right is populated with a target sentence. I cannot edit the source sentence, but I need to be able to select text, copy, etc. A sentence may contain 0, 1, or more “inline placeholders”, which can be thought of as stand-ins for either standalone XML elements, or paired XML elements. As a user, I need to be able to manipulate their placement within the target sentence. These “tags” as we call them, need to stand out from the editable text. We also need text that is different from a previous translation to be highlighted (this word is new, this phrase has different capitalization, etc. ).
Requirements:
- Supports right-to-left text (arabic, hebrew). There are 6 bidirectional unicode markers that need to be supported (supported = edit functions must support displaying text correctly and cursor movement must be appropriate).
- Has option to show/hide invisibles. Each invisible character must be rendered differently (space vs non-breaking space vs en space vs em space vs zero-width-non-joiner, etc.). Ideally, we can define the invisibles we care about. Show invisibles cannot affect word wrapping, or double-click to select a word, or change number of cursor key inputs to move between words.
- Has to have ability to handle the inline placeholders in a smart way. In other words, so user can see which tag is which (they are numbered, and some are start tags, some are end tags), and user cannot mangle them. For example, we currently just treat them as “<1/>”, “<2>…</2>”, etc., and paint them a different color. This is crapalicious. You need several cursor inputs to move past them, you can select/copy/paste/cut part of a tag, etc. I’m thinking an inline image would be better.
- inline spell checking, with contextual menu for learn, ignore, etc.
- highlighting: to show differences to previous versions, we want to use background color style highlighting. Can’t do this in a textarea, so we just use textcolor. Not a great solution because it’s relatively easy to miss, especially when the only thing different is a period or comma.
- type-ahead/auto-complete. With a way to define the list of text, per “sentence”, that will be used for suggestions.
- full support for standard Windows and Mac keyboard shortcuts for editing text. Select next word, to end of sentence, to start of doc, etc.
- “find this word”, “replace this word”, etc., ideally, but at least ability to roll that easily ourselves, as we do with the native textarea.
- Windows and Mac support
- other basic textarea features, such as readonly, select All, characteratXY, events, etc. )
- redo stack (but limited, because our redo is only PER sentence, so if you select sentence 1, edit it, then select sentence 2, edit it, and hit undo a bunch of times, it can NOT go back and edit sentence 1. each sentence has it’s own version history, status, etc.).
Not Requirements:
- Document-level features (our longest “document” is one sentence long).
- margins, tabs, paging, printing, footnotes, endnotes, etc. This is not a word processor.
- ability to save anything.
- hyperlinks
Options
- FTC from BKS (and adapt). Seems like maybe overkill.
- Start over using the new “open source” Text Input Canvas from XOJO.
- Other solution???
What would YOU do?