We have touched upon interoperability in our terminology lifecycle management posts, but today we arrived at a major milestone with our back-end tool, so it’s time for a second helping. It may seem redundant to develop our own software that converts and manages data, when solutions that are available in every LSP’s toolbox, such as qTerm, MultiTerm or Swordfish handle conversion as well to a certain extent. On the bright side, their interoperability capabilities satisfy straightforward and elementary processes; however, as complexity rises, their limitations become apparent.
After zooming through terminology lifecycle management in the past few weeks, let’s continue with off-the-wall Beatles references and a case study.
Earlier we elaborated a bit on various aspects of terminology governance and conceptualization as a method of constructing a self-maintained ecosystem. And now that we have all angles covered, there’s no reason to labour the point, let’s say thank you and good night.
Fortunately for all of us with an inkling to solve problems, once the terminology processes are kicked off and localization is in full swing, issues of different nature are bound to crop up.
The topic du jour is still terminology lifecycle management, specifically governance and maintenance – if you missed the first part, you can catch up here.
Last week we have cut the development and architecture bits short, because they are intertwined with the concept of governance. If you wish to see all the work put into creating, authoring and structuring last another day, factor in roles, responsibilities, communication structure, collaboration model, permissions and transparency.