Missing spaces between sentences

[Dodo1]

Hello all,
we have recently started using Lingo to translate our documentation written in Flare to other languages. However, we have come to an issue I would like to address here (before I submit a bug report), because possibly this might have some solution in settings.

Well, what happens: Lingo takes our source core and digs out one sentence after another to be translated. This works as expected. We translate the terms and build the localized Flare project, and that also works, save one thing: if there were several sentences in a paragraph in the original version, Lingo parses the paragraph into particular sentences, ignoring any spaces written behind full stops. However, when Lingo pushes localized sentences back, it ignores any spaces, which results in a text that is missing spaces behind full stops, and that does not look right. I have attached a small picture to demonstrate the issue:

lingo.gif

Note the red circles, up there is an English original, down Spanish translation.

Any places in our translated documentation which feature spaces behind full stops were done by manually adding a space to the end of the translated phrase, and that is not a clean solution. Anyone knows a way out of this?

For the record, we are using Flare 8.1.1 and Lingo 5.1 (or is it 5.10?)

Thanks for your help.

[techwriter31]

My first thought would be to look at the source code and see if a "<![CDATA[ ]]>" tag is where the space should be. If there is, you could potentially do a find/replace for the CDATA tags, and replace them with "&160;".

[LTinker68]

My first thought would be to look at the source code and see if a "<![CDATA[ ]]>" tag is where the space should be. If there is, you could potentially do a find/replace for the CDATA tags, and replace them with "&160;".

If that's the case, I'd use a blank space in the replace instead of &160;. If you use &160;, Flare will count that as a character so it will in effect combine the two words as one (e.g., set).&160;These), which means it won't wrap at the space because it's a non-breaking space. You could either end up with a hyphen in the middle of that "word" or the whole "word" could wrap to the next line. You could also do a find on two blank spaces and replace with one space if you're worried about the CDATA tag showing up again later (if you have two spaces, Flare will use the CDATA tag to try to preserve those two spaces, especially in print output).

[Dodo1]

No such things as <![CDATA[ ]]> are present in our projects, there are checks running on our source code to prevent them happening. The space there is a "normal" space, like the ones I normally write between words/sentences, using the space bar key on the keyboard. We also sometimes use &160; non-breaking space in the projects, but these are mainly present in empty table cells. or on other special places, and they are put there intentionally. The idea of replacing normal spaces between sentences by &160; (if that would help, that is, haven't tried myself) forces me to shiver... there are thousands of pages in our projects.

As a hint, when there are tags present in the sentences, they are parsed by themselves correctly and when they are translated inserted back, the spaces bordering them from both sides are still present. The same spaces as between sentences, I would say. Just the spaces between sentences are missing when the translated parts are put back together in our projects.

[Dodo1]

Well, we have finally found the reason of this behaviour. When the paragraph is divided into segments, the segments are created so that the "missing" space is added to the start of the second (and any further) sentence, and was not translated by us in that manner. Needles to say that this is not the expected behaviour - my colleague is now submitting the bug report.

Thanks all for advice.