Detecting language please wait for.......
I found that context matches from WorldServer TM don't show in the Analyze Files Report as Context Match but they are included in 100% match. Here is what I found:
Analyze Files Report: 100% x 28 segments (incl. recognized tokens x 2)
Actual count in Editor: Context match (WS) x 18 segments 100% (WS) x 12 segments
Is this by design or a bug? Is there any way to show context matches of WS's TM accurately in the report? I'm using Studio 2019.
What do you mean by Context Match? It's been a while since I looked at WorldServer but from memory only an ICE match in WorldServer is converted to a Context Match (or a Perfect Match) in Studio. It depends on the setting you define in some config file you use in WorldServer that determines whether it's a Context Match or Perfect Match.
So presumably you are talking about ICE matches in WorldServer?
That is correct. An ICE match in WorldServer is converted to a Context Match in Studio and it shows no problem in the Editor view displayed as "CM." The problem is that the Context Match doesn't show as should be in the Analyze Files Report but recognized as a 100% match instead.
Is this an analysis report included in the package? So created by WorldServer as opposed to Studio?
That's a good question. After I opened the project package from a client, I opened the Reports view, so I think it was created by Studio. I also re-ran the report several times and had the same result.
If you look at the results in the TM Results window what do these show? You show the CM matches in the sdlxliff but what's showing against the TM?
I'm not sure if I understood your question but I have attached the screen shot of the report above. Is this what you are asking about? If not, could you please let me know the steps how to see it?
Open your sdlxlff and click into one of the segments with the CM match. What do you see in your Translation Memory result wndow?
I just realized that when I click on a segment with CM (from WorldServer), it shows as 100% in the Translation Results window. This is because it sees the local TM included in the project package, instead of showing the WorldServer TM.
Now I see that my Analyze Files Report is also looking at the local TM, thus showing the complete match as 100%. I think the WorldServer TM in my end is the local TM on the client side, which is why it shows as the ICE match on their report.
Is it possible to create an Analyze Files Report that takes into account the WorldServer TM instead of the local TM?
Reiko Ando said:I just realized that when I click on a segment with CM (from WorldServer), it shows as 100% in the Translation Results window. This is because it sees the local TM included in the project package, instead of showing the WorldServer TM.
Exactly what I wanted you to check.
Reiko Ando said:Is it possible to create an Analyze Files Report that takes into account the WorldServer TM instead of the local TM?
This is only possible if you are connected to the WS TM when the analysis is being run.
I see. But my question now is why the WS CM is shown on the Editor's segments while I have not connected to the WS TM.
Are these static data (i.e., WS CM; screen shot below) added when the package is created by the client? If it shows the actual TM (i.e., local TM) currently used in my environment, it should show as 100%, instead of WS CM, in the each segment on the Editor.
Reiko Ando said:I see. But my question now is why the WS CM is shown on the Editor's segments while I have not connected to the WS TM.
Was the file pre-translated before you got it? If so then these are the results from the clients TM.
I would say it was only partially pre-translated—the CM and 100% match segments were pre-translated when I received the package, but the rest of the segments were blank.
Reiko Ando said:the CM and 100% match segments were pre-translated when I received the package
So there's your answer. The SDLXLIFF already contained the CM matches from WS. You don't have access to that TM so you don't get them.
Thank you for clarifying that, Paul.