It appears that you flat out ignored (or disabled) the warning message that pops up every time you try to open a Publisher file (attached).
There is no problem with Fluency with regards to Publisher. The issue lies in the fact that the Publisher interop is unstable. This (and the fact that professionals don’t use Publisher) are the reasons that CAT tools don’t support Publisher.
Are you hoping to ridicule us to encourage us to fix Publisher support? We’d just as soon remove support for it altogether, but we do have a few users who are grateful for it and understand that they might have to restart their computer a few times or kill the Publisher process that is frozen in the background. Another option that works, sometimes, is to try and save multiple times, which you discovered, but incorrectly attributed to resizing the view of the text (which doesn’t affect the output).
So we let you know before you start that Publisher is unstable and you’ve just spent a bunch of time documenting how it is unstable. To what end?
As for our XLIFF files, yeah they aren’t great, but extremely rarely is someone exporting something from Fluency to another CAT tool.
Western Standard Support
I'm not sure about the part that "professionals don't use Publisher". Certainly graphics professionals don't; when I earned my bread that way I usually used software like PageMaker, Quark Xpress or FrameMaker, nowadays Adobe InDesign seems to be the tool of choice. But I wouldn't think of some engineer in a technical department who uses Microsoft Publisher to write a manual as being unprofessional. Just foolish maybe, but no more so than the ones who use CorelDraw or even MS PowerPoint (!!!) in the same crazy way. People make the choices they do in the circumstances they work in, and professionals try to meet them at least halfway where possible to accomplish the necessary objectives. Fluency does that in the case of Microsoft Publisher, but one would do a service to the customer to suggest that another publishing platform might suit their needs better in the same way that responsible translation consultants often suggest that PDF is perhaps not the ideal format to provide for translation, and that the original format (if it isn't a Microsoft Publisher file or paper) might work better for everyone.
What concerns me about the response of Fluency's technical support, however, is the apparent lack of concern for the compatibility of their XLIFF files. If these cannot be exchanged readily with other platforms, one must ask what actual purpose they serve. Indeed, what would that be? And, perhaps, whether Fluency is really to be taken seriously as a professional platform for translation work.
Some years ago in a period where it looked a bit dark for my platform of choice, I thought that Fluency showed promise as a working platform, and I made a serious effort to investigate its suitability for my routine work as a translator of legal and scientific material. I was charmed by the generally functional approach to transcription, but the translation side of things was less encouraging, riddled with bugs at nearly every stage. After a few days I ran screaming back to more stable, well supported work platforms. The handling of SDLPPX (SDL Trados Studio package files) in particular was the sort of disaster one doesn't easily forget; even with products whose developers care about functionality and compatibility there are issues time and again as the SDL Trados platform evolves. I can only imagine what would happen with Fluency Now if I tried out one of those test files that a friend at SDL likes to play tricks on me with.
XLIFF is serious business. These days it is often the basis not only of interoperable processes with CAT tools but for all manner of bilingual exchange processes. And thus, until the technical support and/or development department of a tool takes this format seriously and makes a reasonable effort to ensure at least basic interoperability, that tool cannot be taken seriously for professional work.
|That should be a question mark, not a period :-)|
I used Fluency for a while a few years ago, when it was a standalone installable program. It was fairly cheap, and we bought a couple of licenses so as to have something on a backup computer that would still allow us to work on SDLXliff files (as Fluency claimed).ReplyDelete
The program, though sold as a professional tool, was barely functional. It had bugs galore, so much so that I don't remember ever completing any project without some serious bug appearing and preventing me from completing the work. It is true that the Fluency tech support people were quick in correcting whatever new bug I had discovered, but working with Fluency felt more like alpha testing (not even beta) than working on a professional tool.
After a few weeks I simply gave up, uninstalled the product, and bought a couple of additional SDL licenses.
A few years ago when I tried the SDLPPX handling in Fluency it was a real disaster. I didn't bother this time; I just thought to take a look and see what had improved (or not) while I examined that *.pub file problem. The bitchy Fluency CTO is wrong in any case; the success of saving a correct target file did in fact depend on changing the font properties for that oversized text. Simply repeating the same operation under the same conditions leads nowhere. I guess I'm not surprised that after all these years the program remains a buggy, unprofessional mess if even a company's CTO cannot get his head around a technical problem properly and resorts to little more than whining and distraction tactics. Meanwhile, other tools (like Wordfast) have shown real progress, even if they don't meet my working specs.Delete