Hi,

this feature will be delivered in one of future CUs - I would say withing a month or so.

Regards

Patrik

Hi Patrik,

This is great news.  Just for the record, I believe that it would be better if the implementation of the OpenDocumentAction would allow you to somehow specify the project the sdlxliff document belongs to.  

From a usability standpoint, It makes a big difference opening an sdlxliff in the context of its containing project, where it has a translation memory attached (among other project-level information) as opposed to open the sdlxliff as a standalone document without any project information.

For example, currently, opening documents from the command line with the /opendocument command-line switch has a totally different user experience if the document happens to be already open in Studio (as the right project is attached in this case) compared to opening the sdlxliff document from scratch with /opendocument with no project selected, because if you do so, an ad-hoc project file is created with the name of the sdlxliff file (which allows to even assign a translation memory different from the one the sdlxliff file belongs to).

In other words, that I think that most likely the best approach segment locator is Project/File/Segment, because "Project" has the information on the context under which the sdlxliff file is intended to be opened under normal circumstances.

It this were to be implemented via the command-line, the command-line switches for a given /opendocument operation would be:

/opendocument -> required

/segment -> optional (default is open in first segment in file)

/project -> optional (default is open file in current project or if not part of project, then create a new project file)

Regards,

Josep.

Hi Patrik,

This is great news.  Just for the record, I believe that it would be better if the implementation of the OpenDocumentAction would allow you to somehow specify the project the sdlxliff document belongs to.  

From a usability standpoint, It makes a big difference opening an sdlxliff in the context of its containing project, where it has a translation memory attached (among other project-level information) as opposed to open the sdlxliff as a standalone document without any project information.

For example, currently, opening documents from the command line with the /opendocument command-line switch has a totally different user experience if the document happens to be already open in Studio (as the right project is attached in this case) compared to opening the sdlxliff document from scratch with /opendocument with no project selected, because if you do so, an ad-hoc project file is created with the name of the sdlxliff file (which allows to even assign a translation memory different from the one the sdlxliff file belongs to).

In other words, that I think that most likely the best approach segment locator is Project/File/Segment, because "Project" has the information on the context under which the sdlxliff file is intended to be opened under normal circumstances.

It this were to be implemented via the command-line, the command-line switches for a given /opendocument operation would be:

/opendocument -> required

/segment -> optional (default is open in first segment in file)

/project -> optional (default is open file in current project or if not part of project, then create a new project file)

Regards,

Josep.

Hi Patrik,

In CU2 released today, the Integration API seems to have been addressed as one of the items reads:

---

* Major enhancements to the new SDL Trados Studio Integration API. With this CU, the SDK documentation has also been updated and developers are invited to start developing against this Community Technology Preview (CTP) release of the API. More information is available for registered developers on the SDK pages at www.sdl.com/openexchange.

---

However, if I go to the SDK documentation for the Integration API, it still says that it is preliminary documentation and it is not evident yet how to open a file at a given segment number.  Is the documentation published for the Integration API up to date as of CU2 or is it still the old one for CU1?

Regards,

Josep.

Hi Josep,

The Document class now has a new method: SetActiveSegmentPair. This allows you to set the active segment pair based on the segment number.

There is currently no way to add and process a custom command line parameter which would be required to implement a /segment option like you mention above.

Cheers,

Erik

Hi Josep,

Having thought about this some more and discussed this internally, I may have a potential solution for you that will allow you to communicate between your own application and Studio through a different mechanism (not a command-line parameter).

You could essentially use Windows Communication Foundation (WCF) as an inter-process communication technology. Something like this could work:

• Create a Studio plug-in and implement an initializer (IApplicationInitializer).
• In the initializer you create a WCF service with an endpoint like this: OpenDocument(project, path, segmentNumber), which uses the API mentioned above to open the document and jump to the segment. Probably make sense to use an IPC binding for this.
• Now, within your application, simply launch Studio, connect to the service endpoint hosted by your plug-in, and call the OpenDocument service method.

You can then also add more functionality to your service to have a more intricate interaction, or communicate both ways if required.

Hope this helps. Let me know if you have any more questions.

Cheers,

Erik