Context matching approach and linguistic efficiency

 
1
0
-1

Hello

Doing some testing and reading the literature, it seems that the concept of CM systematically relies on the project document name metadata.

While this is efficient in case of "continuous localization process" i.e. update of same content name/structure, this seems quite unusual in most cases when even an updated document has a new name (generally v1, v2...).

In addition, a context could be fully identical from previous and/or next segment pov, while belonging to a different client file - the usual definition of a Context Match.

So I see practically no way in this circumstance to obtain 101 or 103% according to T5 approach.

Can you please confirm this analysis?

What are the drivers for this behavior?

Is there any setting that could be done to obtain 'standard' CMs only based on surrounding segments?

Thanks

Vincent

    CommentAdd your comment...

    2 answers

    1.  
      1
      0
      -1

      Hi Marc

      Thanks for taking the time to detail your answer.

      I'm fully aligned with your answers and thanks for sharing about the roadmap item.

      Underlying question, do you plan to make the context matching strict, or flexible with 'previous OR next' (wink)

      V

      1. Marc Mittag

        Right now it is planned as strict. Yet we are always open for input from the community.

      2. Vincent RIGAL

        Making it flexible gives significant advantage to cover the scenario when you would migrate a TM from another CAT that is set with the 'before or after' context only. Hence my question.

        V

      CommentAdd your comment...
    2.  
      1
      0
      -1

      Hi Vincent,

      Doing some testing and reading the literature, it seems that the concept of CM systematically relies on the project document name metadata.

      While this is efficient in case of "continuous localization process" i.e. update of same content name/structure, this seems quite unusual in most cases when even an updated document has a new name (generally v1, v2...).

      this is made for translation of software repos. There the name of a file usually does not change with updates.

      So this is what the 101% match is made for.

      103% match should refer to the ID of a software resource file. Due to a missing link in how translate5, Okapi and t5memory work together, this mostly does not work as it should at the moment, but will be changed this summer, so that it works, as it should (under the pre-condition, that the resource files are correctly configured for Okapi then in translate5).

      In addition, a context could be fully identical from previous and/or next segment pov, while belonging to a different client file - the usual definition of a Context Match.

      yes, I agree, this is the usual way of Context matching. And it will be added in the next months in t5memory and translate5. Already on the road-map and financed.

      So I see practically no way in this circumstance to obtain 101 or 103% according to T5 approach.

      see above. For 103% I agree at the moment. For 101% I do not agree, as in software localization in my experience file names rarely change with updates, if you work directly with the git repo. And this is, what it is made for.

      Can you please confirm this analysis?

      What are the drivers for this behavior?

      Is there any setting that could be done to obtain 'standard' CMs only based on surrounding segments?

      All of this answered above already (smile)

      best

      Marc

        CommentAdd your comment...