Issues with Auto-propagation function

Most often it's required to translate references to UI following this format: "Source" (translation). In case UI reference has a number which variates between similar UI references, Auto-propagate function fails with other instances. See example bellow (red marks incorrectly propagated numbers).

I propose to update Auto-propagate feature to fix these issues. The algorithm could be as follows:

1) If translation has two times more number placebles than source and if each number placeble has at least one counterpart with equal value - we have detected instance where translation follows "Source" (translation) format.

2) By updating each number placeble, its counterpart with equal value should also be updated and then both removed from enumerated placebles. Repeating this step to update all values.

SDL team, do you think this makes sense?

Parents
  • Hi Vilius,

    I don't think it makes sense to change Studio to handle this kind of situation. In your example the AP is working correctly, and the change you propose is far too specific to this problem you are encountering to warrant a complex change like this.

    I think, if it was me, I'd be inclined to try a different approach to resolve a problem like this.

    1. Translate the source correctly into the target file.
    2. Export for bilingual review
    3. Export to Excel
    4. Concatenate the source and target, adding the brackets, into a new column in Excel
    5. Copy this new column and then open the bilingual review file, now paste the new excel column into the target column of the bilingual review file
    6. Update the bilingual review to Studio
    7. Accept all changes and update the TM

    Sounds like a lot of steps, but it's only once at the end, and might be faster than having to edit every segment manually as you go.

    Anyone got a better idea? Anyone else ever come across this problem before? If it's a common problem another useful solution would be to create a new Batch Task using the API. This could do the following:

    1. Translate the source correctly into the target file.
    2. Run the new Batch Task that encloses the target into brackets, and copies the source in front of it for every segment.
    3. It then also exports the target translation

    Probably fairly simple for a developer to achieve this I think and it would ensure the TMs were kept nice and clean and usable for other things too.

    Regards

    Paul

    Paul Filkin | RWS Group

    ________________________
    Design your own training!

    You've done the courses and still need to go a little further, or still not clear? 
    Tell us what you need in our Community Solutions Hub

  • I've given clean example just to illustrate problem with the function. In real life its never this simple, see below:

    As you can see quoted UI references can be in any location of the sentence, thus simple concatenation wouldn't work. Furthermore, these steps would never be approved by translation agencies, because usually there is a translator->proofreader->second editor->in country reviewer involved in the process, where any person may change any part and just expect that Auto-propagation function apply his/hers edits throughout the document.

  • I think you are just demonstrating why it wouldn't be workable to try and ask Studio to do something in an automated way. I'm not sure I have a good solution at all for this. Maybe someone else will do.

    Paul

    Paul Filkin | RWS Group

    ________________________
    Design your own training!

    You've done the courses and still need to go a little further, or still not clear? 
    Tell us what you need in our Community Solutions Hub

  • One way of solving this would be automatic turning this function off when translation is "corrupt" for it, as such instances can easily slip through when translating larger volumes.
  • Good morning.
    I just spotted an issue in a file am working on and I wonder if this is also related to a faulty auto-propagation. It is related to a segment that starts with a number value but what is odd is that what changes is the text and not the number. See below:

    Even though it mentions that the translation is a Context match, in the translation memory I am working with, both central and project TM, this translation does not exist. The one that does exist is 1000 miles = 1.000 millas, and this segment also occurs in this same file only a few segments down. Have you noticed this kind of issue before?

    Thanks, Sónia

  • Good morning Sónia, that's an interesting one.  Looks buggy to me but I will check with the team here and let you know.  I did a quick test like this:

    I confirmed #1 and this autopropagated #2 which had the same number value but a different unit.  This is clearly incorrect behaviour, but it's also explainable I think.  If you put the cursor into #1 you see this:

    Note that the entire number and it's unit is recognised as a single placeable.  When you go to #2 then "1000 km" is also recognised as a single placeable and as you translated this previously Studio just says, ok here's another placeable with the very same number so I'll do what I did last time.  It seems to be ignoring the unit and just reading the number.

    I think that's a pretty loose explanation, because if it was consistent I would have expected "1234 miles" and "1457 km" to do the same thing which it doesn't.  It onoly does this if the numbers themselves actually match.  But I think it's got something to do with this.

    I'll let you know what the team have to say and what we can do to resolve it permanently.

    In the meantime I think the best approach is to not change "miles" to "millas" as you translate.  Rather allow Studio to get the numbers right and the units wrong in a consistent way and then at the end of the translation just do  global search & replace in one go.  This will save you a lot of headaches and it'll be much faster.

    Regards

    Paul

    Paul Filkin | RWS Group

    ________________________
    Design your own training!

    You've done the courses and still need to go a little further, or still not clear? 
    Tell us what you need in our Community Solutions Hub

Reply
  • Good morning Sónia, that's an interesting one.  Looks buggy to me but I will check with the team here and let you know.  I did a quick test like this:

    I confirmed #1 and this autopropagated #2 which had the same number value but a different unit.  This is clearly incorrect behaviour, but it's also explainable I think.  If you put the cursor into #1 you see this:

    Note that the entire number and it's unit is recognised as a single placeable.  When you go to #2 then "1000 km" is also recognised as a single placeable and as you translated this previously Studio just says, ok here's another placeable with the very same number so I'll do what I did last time.  It seems to be ignoring the unit and just reading the number.

    I think that's a pretty loose explanation, because if it was consistent I would have expected "1234 miles" and "1457 km" to do the same thing which it doesn't.  It onoly does this if the numbers themselves actually match.  But I think it's got something to do with this.

    I'll let you know what the team have to say and what we can do to resolve it permanently.

    In the meantime I think the best approach is to not change "miles" to "millas" as you translate.  Rather allow Studio to get the numbers right and the units wrong in a consistent way and then at the end of the translation just do  global search & replace in one go.  This will save you a lot of headaches and it'll be much faster.

    Regards

    Paul

    Paul Filkin | RWS Group

    ________________________
    Design your own training!

    You've done the courses and still need to go a little further, or still not clear? 
    Tell us what you need in our Community Solutions Hub

Children