• State Verified Answer
  • Replies 6 replies
  • Answers 2 answers
  • Subscribers 433 subscribers
  • Views 2822 views
  • Users 0 members are here
Options
Related

Studio 2017: FrameMaker Variables treated inconsistently

Stefano Bellezza

We use FrameMaker 11/12 for our documentation, and we have been representing the name of our flagship product with a variable (shown in Studio as a <v type="Product Name Short"/> tag).

Studio 2011 processed this tag correctly. Studio 2014 seemed to have issues: the variable was at times left out of the segment it belonged to, as in

[missing tag would be here but it's not] aligns the melody note events with the nearest bass notes.

It doesn't quite matter that the tag is at the ends of the segment or within: sometimes, the variable is treated as a segment break - which is obviously even worse.

For some time, our workaround has been to convert the files using 2011 and processing the SDLXLIFF files in 2014, wich was a chore.

Recently, after performing extensive tests to make sure that the issue had been addressed, we updated to Studio 2017. Everything seemed OK for some time, until today I began processing the files and experienced the issue again. As I said, it is erratic and inconsistent: in the same file, I get this

and this

(obviously, "aligns" should be preceded by a tag)

There does not seem to be a connection between the behavior and a segment being new or not. My settings haven't changed over the years:

Any insight/workaround? This is a big deal for us, it basicaally had us skip the Studio 2015 update; and we cannot go back to the old workaround of using 2011 to convert MIFs to translatable format since we no longer have a license for it (plus, overhead).

Thanks,
Stefano
Rate translation
×
Suggest better translation
×
Moderator UI
×
  • Get AI Suggestion
Parents
  • 0
    Hi Stefano,

    Please can we see a file like this? You can email it to pfilkin@sdl.com

    Thank you

    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

  • 0 in reply to Stefano Bellezza

    Hello ,

    Apologies for the delay in responding.  First of all I tried to verify this in 2011 but that version won’t open these mif files at all.  So I used 2014 and this allowed me to reproduce your problem.  In 2014 I see this:

     

    In 2017 this:

     

    Note that you can see the tags if you use the display filter in the Review ribbon and filter on All Content as I have done here.  You can also drag them into the target segment if necessary and this may be helpful while we investigate this so you can at least place them where you like in the target text.

    Now, if I compare this with a “good one”:

     

    The problem is now reasonably clear to me.  I believe Studio may have been “fixed” to move opening and closing tag pairs externally if they are empty because they are not needed, and as they are preceded in this case by a placeholder tag Studio is assuming that all of the tags can be moved out of the way so you don’t have to deal with them.  Unfortunately in your case you do.  So the superfluous bold tags seem to be causing the movement of the tags outside the translatable area.

    So whilst I think this behaviour is intentional I will discuss it with the development team to see what they think.  In the meantime try dragging them in like this:

    Hope that's clear and you have a bit of a workaround for now until we determine whether this is anything we can sensibly fix with an option or not.  I can imagine there are occasions when you'd prefer these tags to be moved away, so it's probably a tricky one to get right for everyone without making this an optional thing.

    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

  • 0 in reply to Paul
    Hi Paul, hi Stefano,
    thanks for sharing these Information!
    We have found similar issues with v-tags and af-tags in Studio 2014 and 2017. We have instructed our translators to use the All Contents drag&drop workaround for Studio 2014, but it can be a bit dangerous. Therefore we have had high hopes for Studio 2017 where this issue has been fixed - but not completely, as Stefano has shown.

    I would just like to mention that this inconsistent behaviour has also consequences for the TMs (the TUs are stored with/without leading/trailing tags) and therefore has an impact on TM size, consistency, reuse and thus costs. So we would really appreciate if the behaviour is consistently fixed in an early (one of the next) builds in Studio 2017 before we and other SDL customers who heavily use MIF roll out Studio 2017.

    Kind regards
    Christine
  • 0 in reply to Paul

    Thank you, Paul. I didn't realize that there was an "All Content" command - and trust me, I've been looking for it for a while!

    The only problem I see with your workaround is that I have not been able to similarly fix the source segment (Studio categorically refuses to let me drag the tags in, no matter how many times I tell it to unprotect tags and let me edit the source), so I would be committing TUs where source and target are not perfectly aligned (as rightfully pointed out). Not very risky in this particular instance, but you can see how it could become dangerous under different circumstances. Anyway, we'll make do with it for the time being.
Reply
  • 0 in reply to Paul

    Thank you, Paul. I didn't realize that there was an "All Content" command - and trust me, I've been looking for it for a while!

    The only problem I see with your workaround is that I have not been able to similarly fix the source segment (Studio categorically refuses to let me drag the tags in, no matter how many times I tell it to unprotect tags and let me edit the source), so I would be committing TUs where source and target are not perfectly aligned (as rightfully pointed out). Not very risky in this particular instance, but you can see how it could become dangerous under different circumstances. Anyway, we'll make do with it for the time being.
Children