Start a new topic

Dynamic switching of parser

 Today, I created a new English-Japanese project after finishing a J/E project, and noticed CT did not automatically switch to word-by-word matching.

I cannot reproduce it yet. Was it CafeTran's project or a project created in another tool? Are you sure you switched the language pair?

Both were native CT projects ... anyway, I will contact you again if this issue occurs again.



I may have forgotten to change the memory matching type.



This issue is occurring again.

For example, the memory matching type of an existing J/E project (Fuzzy without word separator) is changed to Fuzzy when reopened after an E/J project (Fuzzy) is worked on, and vice versa. Every time I quit a project, I save it, but it seems that this parameter is not always retained.

  1. Do I have to change the language pair on the Dashboard every time I open an existing project?
  2. Can I avoid this issue by using a template? (Can I specify the memory matching type in each template?)

Thanking you for your help in advance,


Can you provide simple steps (how you switch projects) to be able to reproduce it?


I have created two projects for review (reversed language pairs). Please switch between them, and you will find the parser of either is incorrect (affected by the last opened project).


(47.3 KB)
I personally think that instead of dynamic (automatic) switching, it would be safer to pop up a selection panel (like the one below) every time an existing project involving one of the CCJK languages (and other languages known not to have a word separator) is opened.

Provided that it'd not be disturbing other users ...

Please select the memory matching type.


Switching languages switches the matching type automatically. However, the Matching type field still shows the last selected option after the right-click at the TM panel, leading to a possible confusion. The new build of update 14 (2017062001) fixes it.

I would like to request that the matching type (Fuzzy) is also remembered for an EN-JA project. Currently, the matching type is automatically set as Fuzzy and Hits when such a project is opened after a JA-EN project, despite the previous setting.


Another issue is that when an EN-JA project is opened after a JA-EN project and the memory matching type is automatically set as Fuzzy and Hits, it seems that glossaries are searched on a character-by-character basis. I can tell this from the fact that short abbreviations (like "UN") appear as matches for part of longer terms (like "unhappy" or "blunt").


Please check the reversing of languages which triggers the glossary parser switch in the latest build.

Login to post a comment