Start a new topic

Non-translatable glossaries

It would be very nice if the target box content would be completely ignored when adding words to a Non-translatable glossary.


Now you have to unselect any text in the target segment editor or remove the content of the target box in the New term dialogue box.


There is no point in selecting anything in the target segment when you add a source fragment as a non-translatable. As the name suggests, it is not to be translated.

Yes, there isn't. But many times:

  • Either the text caret is in the target box when you make a selection with the mouse in the source box, in that case: the target is inserted in the dialogue box, or
  • You enter a new segment, no editing is necessary, just want to add a string to the non-translatables, in that case, you just double-click on a word in the source, and ... the whole content of the target is added to the dialogue box

Is there any difference between adding a term to a specific "non-translatables" list and creating a glossary entry where the term appears both in source and target?


The latter would allow these to be inserted into a specific project glossary and alleviate the need to create project-specific "non-translatable" lists (which just means more files and more confusion to a project, I'd say)

>Is there any difference between adding a term to a specific "non-translatables" list and creating a glossary entry where the term appears both in source and target?


Yes. Only non-translatables will be excluded from spelling checks.

I often do both, tough. A problem is that I personally think that the non-translatables has the highest priority, so even if a term is present in a glossary too, I think it should always be marked purple.


>The latter would allow these to be inserted into a specific project glossary and alleviate the need to create project-specific "non-translatable" lists (which just means more files and more confusion to a project, I'd say)


The confusion can be avoided/worked around by designing a systematic approach.

> The latter would allow these to be inserted into a specific project  glossary and alleviate the need to create project-specific  "non-translatable" lists


That's pretty much possible. Just precede your non-translatable term with the ! character as you add a new term to the glossary.


2 people like this

Thanks. Does that ! go in source, target or both? For instance:


New term:

source: !Giovannoni

target: Giovannoni


This ok? What does ! do? Ignore the term during a spelling check?

The ! character tells CafeTran that this is a non-translatable term included in the normal glossary. You don't need to add this character if your glossary is set as non-translatables only.


You can leave the target box empty for non-translatable terms when you add them to the glossary.


1 person likes this

Remarkable, although the glossary item preceded with an exclamation mark was entered as a normal glossary entry (in a normal glossary), the item is coloured purple, instead of orange (on my system the colour for glossary entries). Exactly as it should be. This gives me food for musing over my workflow.

In contrast to regular expressions in non-translatable-only glossaries, is it possible in normal glossaries where non-translatables are marked with an exclamation mark, to include any trailing closing bracket?


image


In a non-translatables glossary this would be: 


|db\(A\)

I don't think you need any slashes before brackets as these are not regular expressions.

This "!" magic is best-est-est thing since sliced bread! It even works with QA and allows me to use just one project-specific glossary, I'm amazed. Thank you! 

Login to post a comment