Start a new topic

Non-translatables vs TM match background color highlighting


Should non-translatables background color highlighting take precedence over TM match color in the source segment editor?

I think they should, in contrast to what is currently being applied.

Reasoning: especially for user-defined non-translatables, the purple highlighting should remain on-screen even if they also appear in a TM match, to hint the use of the F4 shortcut. This way, the translator can be sure to apply the non-translatables when needed. if a TM match also includes non-translatables, this can be hinted by the presence of the green background on the space before and after the non-translatables (no white background color between words). The contrary can’t be applied to non-translatables, which are typically shorter than potential TM matches.

What do you think?


1 person likes this idea

I have been requesting this since non-translatables were introduced (though for glossary entries, but that's not relevant in this regard).

If I'm not mistaken, the colours are right when a non-translatables are added to normal glossaries (not non-translatables glossaries) and marked there with a leading exclamation mark.

If that is right, it would make sense to make the behavior consistent no matter what method is used for storing non-translatables (Resources > non-translatable fragments, non-translatable glossaries or normal glossaries with entries featuring the leading exclamation mark).

One additional request: When an item has been defined as a non-translatable, it should never be translated by any entry of another glossary.

So, if 'SI' is a non-translatable, it should stay that way and not be translated with 'System Internationale' or another translation.

One could say, non-translatables should be locked.

Igor, thank you for applying this suggestion!

While this is a great improvement, there still seems to be a glitch (but hey, that's what we are for: to report them ;) ).

Correct colour-marking

Before 2018-10-04:


With today's update:


However: There is no item in the F4 pick list for 'Gold Peak':


(The sub-items 'Gold' and 'Peak' have been added to exclude them from Hunspell.)

I have a non-translatables glossary with just one entry:


And I have this segment:


When it's assembled, I see the string EN ISO 12100 marked purple. After 1 second, the display is as shown above.

F4 shows the correct non-translatable:


Why isn't the non-translatable marked purple permanently?

That's an overlapping case. Longer highlights containing the shorter ones can hide the latter.

>Longer highlights containing the shorter ones can hide the latter.

Yes, but don't you agree that they shouldn't be hidden?

If I have the entries:







the longes possible (= covered) non-translatable should be coloured purple, don't you agree?

In case of overlapping, the current algorithm has the preference for the highlight of glossary terms or TM fragments (mostly for speed reasons). 

>In case of overlapping, the current algorithm has the preference for the highlight of glossary terms or TM fragments (mostly for speed reasons). 

That's strange, since directly after auto-assembling, the non-translatable is marked in its longest form. After a second, it's marked in a shorter form.

> After a second...

After a second, the glossary/TM matches arrive.

Yes, I understand that. But then I don't understand the part mostly for speed reasons: if the longest non-translatable is already coloured, why change that?

> why change that?

To highlight the complete phrase.

> mostly for speed reasons

It would require analyzing every character in the current segment to check if it is already highlighted as a non-translatable. Then, it would have to determine (search for) which part of each glossary term and TM fragment belongs to the non-translatable category.

Login to post a comment