• State Verified Answer
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 393 subscribers
  • Views 10205 views
  • Users 0 members are here
Options
Related

Adding comments to segments

Tamas Meszaros

Hi,

I would like to add comments to paragraphunits in an existing sdlxliff document this way:

var pup = Controller.ActiveDocument.ActiveSegmentPair.GetParagraphUnitProperties();
pup.Comments = CreateComment(doc.PropertiesFactory, "abc", "xyz");

where

ICommentProperties CreateComment(IPropertiesFactory pf, string commentText, string origin)
{
var commentProperties = pf.CreateCommentProperties();
var comment = pf.CreateComment(commentText, origin, Sdl.FileTypeSupport.Framework.NativeApi.Severity.Low);
commentProperties.Add(comment);

return commentProperties;
}

But this does not seem to change the original segment. When I query the ParagraphUnitProperties again, the comments property is null again.

I also tried to reach the paragraphunit as ActiveSegmentPair.Target.ParentParagraphUnit, but it returns null.

Does anyone have an idea how to add comments (maybe also structure info) to existing segments?

Thanks,

Tamas
Rate translation
×
Suggest better translation
×
Parents
  • 0

    You have use the Bilingual API to add comments to an SDLXliff file. You can find an overview of the bilingual api here:  

    In essence you need to create an extension to the sdlxliff file type using FileTypeComponentBuilderExtension class. You can read more on how you can do that here. Also you can have a look at this plugin source code which is extending xliff file type.

    I've also written an article about how you can access segment tags using the file type framework which uses the exact mechanism as the one you need to implement for adding comments. You can read my article here:  

    The main objectives of the Integration API are to provide ability for the developers to create new views and view parts, extend the ribbon menu, create AutoSuggest providers and  ways to hook on main Studio views (projects, files, and editor). This API is more about extending the UI which was something very limited with the other API's

    Hope this helps.
  • 0 in reply to Romulus Crisan (former member)
    Hi,

    thanks for the answers. The problem was that the ActiveSegmentPair.[Source|Target].ParentParagraphUnit was not accessible, because it returned always null, though, the ActiveSegmentPair.GetParagraphUnitProperties() returned something, but it was cloned, so read-only.
    (I think this is a bug, I mean that .ParentParagraphUnit returned null, isn't it?)

    But found a workaround: we can get the paragraphunit using reflection this way:

    ((ISegmentPair)(Controller.ActiveDocument.ActiveSegmentPair.GetType()
    .GetField("_segmentPair", System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.Instance)
    .GetValue(Controller.ActiveDocument.ActiveSegmentPair)))
    .Source.ParentParagraphUnit

    Regards,
    Tamas
  • 0 in reply to Tamas Meszaros
    Nice workaround. However, I don't think this is a bug and they are doing it on purpose.
  • 0 in reply to Jesse Good
    Maybe I wouldn't quite word it that way, "... doing it on purpose"! But it's not a bug, it's just not a public API which means if we change the software we might do something that could affect your use of this call and we won't support it. I'm sure Romulus will pick this up and review what's needed to make sure we can provide a proper way to support this requirement with a public API in the future. That's what this community is all about!
  • 0 in reply to Tamas Meszaros

    Your workaround is working at the moment but you are taking a big risk since the object you are loading using reflection it's not part of the public Studio API. Not being in the public API means that SDL might change the current behavior without informing anyone and your code will no longer work. I'm not saying that the public API is not going to change but it will be done in multiple steps to give developers time to adjust their code and also alternate approaches will be recommended. 

    By directly operating on segments/paragraphs you might break internal Studio cursor/selection logic. This is the main reason why the objects you can access using Integration API are cloned objects and not the actual objects.

    I do admit that the alternate solution from my initial reply adds more complexity to your plugin and also  require more coding but for the time being this your safest bet. There are plans to improve integration API by creating operations that can update properties or can make operations on segments/paragraphs. This objects will still not be directly exposed since we need to control how they are updated. This should be released in the first part of the year but this is not confirmed and it might be postponed.

    PS: Your solution is not entirely correct and I will remove it as an accepted solution since it might mislead other developers. I will leave it as a suggest answered but I would like the developers to read the entire discussion and get all the details.
Reply
  • 0 in reply to Tamas Meszaros

    Your workaround is working at the moment but you are taking a big risk since the object you are loading using reflection it's not part of the public Studio API. Not being in the public API means that SDL might change the current behavior without informing anyone and your code will no longer work. I'm not saying that the public API is not going to change but it will be done in multiple steps to give developers time to adjust their code and also alternate approaches will be recommended. 

    By directly operating on segments/paragraphs you might break internal Studio cursor/selection logic. This is the main reason why the objects you can access using Integration API are cloned objects and not the actual objects.

    I do admit that the alternate solution from my initial reply adds more complexity to your plugin and also  require more coding but for the time being this your safest bet. There are plans to improve integration API by creating operations that can update properties or can make operations on segments/paragraphs. This objects will still not be directly exposed since we need to control how they are updated. This should be released in the first part of the year but this is not confirmed and it might be postponed.

    PS: Your solution is not entirely correct and I will remove it as an accepted solution since it might mislead other developers. I will leave it as a suggest answered but I would like the developers to read the entire discussion and get all the details.
Children