> this argument is rather ugly
Yes, it is but I don't really care as such arguments are the least convincing and the first to ignore completely.
Anyway, I think an option in Preferences to ignore (not match) user-defined morphemes might be added in the near future to cover all similar cases. Instead of hard-coding them, the user of a specific language will be able to define those few prefixes.
Yeah, I have been getting that too: entries in my glossary are not being highlighted if they are touching a comma, apostrophe, and a number of other characters, which is a pain in the ass.
Michael
… and same for Europe => Europa when after an apostrophe (just in case Amérique is claimed to be too exotic or not included in Hunspell).
A few tips to match phrases with apostrophes:
1. Perform the manual search. You should find what you are looking for.
2. Keep apostrophes in your multiword glossary phrases (e.g. l'Amérique du Sud - Südamerika).
3, Load your glossary via the Memory interface (Memory > Open memory). It provides full fuzzy matching for longer phrases.
Curly apostrophes in the source segments can be easily replaced by the straight ones by Edit > Find > Replace all if they really hinder automatic matching for you. The apostrophe thing can also be solved by applying more fuzzy algorithms. However, users will start complaining about scrolling too much to locate their match in tens of similar results. The current algorithm is tuned to find the proper balance between the number of the results and limited fuzziness.
Tre: This would mean to get a bunch of segments where terms are recognized or perhaps not. Let's take a segment of 50 words with 6 terms (and one with an apostroph). I will see the six terms, but not the seventh.
In my test, both "l'Amérique du Sud" and "l’Amérique du Sud" were recognized in this QA check, so I think it should work for all exact term occurrences.
A specific language User's dictionary can be edited in Edit > Edit user's spelling dictionary, if you load a project that uses that target language. You can install the French hunspell dictiionary even if you don't translate to that language.
That's all clear. I am already not convinced of the approach that only single words out of Hunspell are being recognized after an apostrophe in CT, so now create an extra project (FR Hunspell is installed anyway) to include terms or term variants that are not in Hunspell? Seriously? Only to recognize a term behind an apostrophe? This might be okay for us who love fiddling around with files and playing with text editors, but for most users not. And up to now this all is not even documented (perhaps the process of documentation might reveal how cumbersome this is).
... while even the simplistic tool OmegaT offers this feature (see above, sorry, this argument is rather ugly).
Why do you do b) if a) works "like a charm" for you. I wonder what you wish to achieve by making CT treat your apostrophe as a space.
> No chance to recognise two- or more-word glossary entries with apostrophes?
It's not clear to me either. If you have two or three word phrase in the glossary, then you should expect exact matching for such multiword glossary phrases. If you expect fuzzy matching, use translation memories instead.
> It's not clear to me either. If you have two or three word phrase in the glossary, then you should expect exact matching for such multiword glossary phrases
But this is exactly the point. They are not recognized when being behind an apostrophe (as said above, the flavor of apostrophes might differ, depending on several factors)
If you wish any character to be skipped during matching add it to the "Do not match" list in Preferences. That's a fast solution to remove any characters that might interfere with the matching of words or fragments.
Hmm, I checked, and the comma is in that list. I will try to see if it happens today and send in some screenshots. Here is my current list:
,.。:;!¡?¿[]"«»‘’“”„'’()
and written differently:
,
.
。
:
;
!
¡
?
¿
[
]
"
«
»
‘
’
“
”
„
'
’
(
)
So any terms with the comma should be recognized and displayed in the Matchboard. They should also be highlighted in the source segment. There is only one current limitation to the highlighting. CafeTran does not highlight the phrase in the source segment if such a character is in the middle of the matched phrase. The Matchboard shows such a phrase just fine.
tre
Simple detail question:
How can I make CT recognize this term?
Please note that there are different occurrences
Note the difference in the apostrophes (the 3rd case is quite seldom). It depends on programs and some other aspects, which apostrophe is being used.
If I understand correctly, I have the following options
Perhaps I oversaw something?
The handling of terms with apostrophes concerns users translating from Fench, Italian, Catalan and many more (that I might ignore here). I do not think this is an exotic problem.