I never understood why non-translatables don't respect word boundaries. I have a non-translatables 'ger' (or even 'GER'), which is often used as an abbreviation for Germany Diesel Land. In translation tables for industrial automation (and elsewhere) this 'GER' should be treated as a non-translatables. So it deserves its presence in my list of non-translatables.
That being said, I don't understand why 'ger' is highlighted here:
To be honest, I find this distracting. And you heard me talking (yesterday) about how I prefer a 'relaxed translation mode' ;).
Seconded. I would also like a kind of marker to include an optional case sensivity inside a glossary (without being forced to create a second one), but this might be another question.
BTW: ‚gerinst‘ is really funny. I never heard this word before, though I understand it from the English term.
>Seconded. I would also like a kind of marker to include an optional case sensivity inside a glossary (without being forced to create a second one), but this might be another question.
I guess so (since I don't understand what you are saying ;))
>BTW: ‚gerinst‘ is really funny. I never heard this word before, though I understand it from the English term.
I find this dealing with 'funny' words one of the most beautiful aspects of my work. I can really enjoy a good word. I often cannot get it out of my head ;). Beroepsdeformatie?
Simple example: if I want to enter "CE"/"EU" as a case sensitive term, and so to ignore any occurrences of the French "ce" (and who said "stemming" out there?), I need a create/open a new term base, but I prefer the Big Papa approach. A term base for a specialization or for a stubborn client, okay, but one for case sensitive terms?
Or did I miss any new feature in the last years?
@Torsten: I have asked this before, can't remember when, but it would be great if we could make individual entries in glossaries case sensitive or case insensitive, rather than only entire glossaries.
I like to store abbreviations and acronyms in my big glossary, but if I have it set to case insensitive (which I do, to catch more), many very short terms then get incorrectly highlighted in the src text as matches.
Another example to show how non-translatables can create a colourful world:
> I never understood why non-translatables don't respect word boundaries
Some languages do not have word boundaries so the current implementation is a generic one to cover both types of languages, with or without word boundaries.
That's interesting. Have you designed CafeTran for such languages too right from the start?
Yes, when introducing a feature, I need to take both types of languages into account.