… 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).
So what was recognized in your 'temporary success" above?
It is really confusing. Once you claim that "Only Amérique as one-word term" is recognized, a few posts later you say it isn't.
Between your trials you seemed to have played with various glossary options for matching as well as with the "Do not match" list. Perhaps restoring them to the point where it worked for you might help.
I will test this thoroughly in the next days.
If I understand correctly, this is the actual and optimal state of the glossary function in CafeTran. What means that CT gets unusable to check files against client's glossaries, at least with FR or any other language with many apostrophes in use (and multi word terms are quite common in French texts).
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.
I only occasionally translate from French into Greek, as I generally work on the EN/EL>FR language pairs.
I could not make extensive tests, but in my quick run:
I confirm the behavior with multiple and single word glossary/fragment entries when there is a curly apostrophe:
If the straight apostrophe ' is used, single word glossary/fragment entries are recognized and highlighted.
Depending on fuzzy matching settings, this could indeed be catched by the TM for longer phrases.
With Preferences > Workflow > "Automatic selection of whole words" option enabled, I have noticed that a word is selected along with the text characters before the straight apostrophe: For example, "l'Amérique" is selected (and recognized) as one word. This does not happen with the curly apostrophe or the other more exotic one used in tre's example.
Because the curly apostrophe is very frequent in French, but also in several other languages I think, apart from the very valid suggestions above (especially the one about replacing the source apostrophes), at least for one word matches, it could be useful to make CafeTran recognize "l’Amérique" (with the curly apostrophe) as one word as well. Does this depend on a user-defined setting or happen at the application level?
I do not understand that CT is able to detect many, many terms in different contexts correctly, with and within quotation marks, parenthesis, tags and so on, it even finds as in jack-ass with the corresponding setting. But why not behind apostrophes (that are not something special of a Subsaharan local dialect)? Why would this lead to many false matches?
And then there is still the glitch in the Frequent words feature here.
CafeTran has tons of settings, but actually – if I understand correctly – his kind of recognition fails on application level. Please correct me if I am wrong.
When doing sometimes proofreads with an obligatory client glossary, you could also be concerned.
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.