Problem with recording very long sentences -- don't fit on the screen

(First thank you HearThis team for adding the French interface.) Four of our teams in Gabon, central Africa are currently at a mini-workship trying to record Luke 1-5. They’ve discovered two problems. One is that in the geneology passage of Luke 3, teams that separated the geneologies with commas have a sentence that is 15 verses long. This of course is one segment in HearThis, but it is way to big to fit on one screen (no scroll down feature). So the only way to record this it seems is to put in artificial periods for the recording, and then to take them back out in Paratext later for the print version. Is there another way to deal with this? This is the kind of thing that if there was a hint about it in a Help file or ReadThis doc, that could be useful.

This question has been addressed before: Facing problem in recording. (The answer may not be entirely satisfactory.) Also, see: Allow for many (not only 2) segments in Record Long Line in Parts dialog.

Thanks, Tom. I see the discussion now in “Facing Problem in recording.” Part of the answer to the question “why not just break this into small sentences” is that we often teach our translators to follow print English/French versions when they are unsure of how to format or punctuate something. Most versions separate the genealogies in one big block by commas. These are short little segments and still pretty easy to read in a publish Bible. So we could change commas to periods, but we would only be doing that for HearThis. Maybe the answer here is that when recording the genealogies, they should shift over to reading them off a print copy, instead of the HearThis screen. And yes if at some point the Record Long Line in Parts could support more than 2 parts, that could be helpful.

Obviously, ultimately we don’t want people messing up their translation to accommodate inflexible software. So a good solution is needed.

Just tested a mild hack and published it in the other thread about this problem:


I can’t tell you what to do, but it is generally discouraged to use a Unicode code point that has a glyph that looks right but has a different meaning. I do understand the temptation to try to hack your way around a software deficiency (and I am truly sorry that this deficiency has been left so long without being adequately addressed), but there are often hidden pitfalls in such workarounds. In this particular case, a few of the possible pitfalls might include:

  • Software (like Glyssen) that attempt to analyze your data and make assumptions about how your language uses quotations marks could be confused by these unexpected quotation marks.
  • Although the glyphs may look identical (or almost identical) in one font, in another font, they might not. You may be able to control which font is used in a particular print publication, but future developers/users of derivative products (apps, websites) might be surprised when a different font is used and things look funny.
  • Searching for a particular string with a comma will only find matching strings that use the same code point. That could cause some confusion.
  • In Paratext, you will need to tell it about additional characters and punctuation patterns that are valid. But you won’t easily be able to indicate when and where they are valid. If someone copies text from one place and pastes it into another, they may inadvertently be copying the wrong kind of comma, but no checking tools will be able to alert them to the mistake.

So if you do proceed with this approach, please consider how to mitigate the above issues. I do hope a better solution can be found soon.

Thank you Tom for giving your condolences re the software deficiency. And about listing pitfalls and some ideas on how to limit the dangers.

Just for the record, I agree with all your points - and when I shared that I did a mild hack, of course I left plenty of documentation (not last on this forum) and considered that my one solution would not create two follow-up problems.

I just love to remind about the real life situations, i.e. all that happens once the tools have left the devs lab or set-up: We use a tool and we get stuck in the middle of a project (for example while audio-recording a certain gospel). Now just leaving a hole is also discouraged, because it will frustrate or confuse users (who will believe there is a problem with their app or browser or they might draw conclusions about the publisher being sloppy or whatever).

One could also spend a few days, getting another tool, digging deep into the data levels and use another pro-tool to record and splice-in the missing portions which Hear This cannot handle properly (yet). But that would make the “easy approach” of Hear This rather useless for projects like ours:

I am in charge, I can “do pro stuff” but I am far too busy. So I quick-train another team-member on an “easy tool” and am happy until the day it all cloggs-up and I have to spend even more time analysing, searching online, reading other user input, finding no hack, making a mild hack, later defending the hack.

Other users, please understand that I love and appreciate Tom a lot. And his work. And I repeat that he is right. So do not do it, unless you can handle it. Just if your tool cannot record your text, you need to find solutions - or leave gaps. Please share how you created your own solutions respectively.

Normally at this point, I would offer to be be available for testing when the real official fix is being made. But this time I happen to be travelling in another continent, far from the project. But the problem is rather well defined so once fixed, that should be obvious and should be easy to confirm. Thank you Tom for keeping this issue alive.