| Pages in topic: < [1 2 3] > | Free, online CAT tool looking for beta testers Thread poster: Philomelius
|
|---|
| More desireable formats to be supported | Dec 9, 2013 |
Selcuk Akyuz wrote: Supported formats
Word (all versions), PowerPoint (all versions), Excel (All versions) Open Office (all versions) , .txt, .rtf, XML (all versions), HTML, xHTML, TMX, XLIFF, TTX, ODD (all versions), comma separated values (.scv), tab separated valued (.tsv), DocBook and of course PDF. Need more formats? Let us know.
InDesign, InCopy and FrameMaker are supported by almost all CAT tools. Perhaps you can add support for sdlxliff, mqxliff, txlf formats as well. And PO files. Selcuk
... txml, Star Transit, maybe some plugins for the most frequently used CMS solutions, something in the style of the good old T-Window for Clipboard
XLIFF in all possible dialects is a must though.
| | | | Philomelius
Local time: 12:40
English to French
+ ...
TOPIC STARTER | PO files are supported, but we had to make choices | Dec 9, 2013 |
SDL formats are hard to convert (for no reason than SDL is making them so) and we had to set some priorities. More formats will come depending on feedback from the community. Sorry if this is an inconvenience to you.
Edit: I realize I did not mention po files in the accepted formats list. I will go hit myself on the head now.
[Edited at 2013-12-09 22:09 GMT]
| | | |
... but most other CAT tools seem to have no problem handling SDLXLIFF that is essentially XLIFF. What do you find so hard about this?
Regards
Paul
| | | | Gyula Erdesz
Hungary
Local time: 12:40
Member (2009)
English to Hungarian
+ ...
| Devil is in the detail. | Dec 10, 2013 |
SDL Support wrote:
...SDLXLIFF that is essentially XLIFF.
Essentially, as giraffes are essentially horses...
Cheers,
Gyula
| | |
|
|
|
Philomelius
Local time: 12:40
English to French
+ ...
TOPIC STARTER
And dear Paul, I wish what you said was true. Where were you when I couldn't upgrade to SP3 and had to wait three weeks for SDL support to contact me, by the way? Nice to see you in this thread!
Joking aside, SDL proprietary formats are seldom used by agencies because of the overwhelming complexity and lack of support of the SDL product suite.
We will integrate your formats though, but as usual, it is regrettable that SDL formats are so intentionally hard to convert ev... See more And dear Paul, I wish what you said was true. Where were you when I couldn't upgrade to SP3 and had to wait three weeks for SDL support to contact me, by the way? Nice to see you in this thread!
Joking aside, SDL proprietary formats are seldom used by agencies because of the overwhelming complexity and lack of support of the SDL product suite.
We will integrate your formats though, but as usual, it is regrettable that SDL formats are so intentionally hard to convert even though they are essentially XLIFF, XML, etc., with an unnecessary proprietary later, turning universal, open formats painstakingly developed by others into proprietary ones.
You are, by a large margin, the only publisher to adopt such practices. I guess you think it locks down your customers, hindering their ability to change tools, but history has proven that it seldom works. Have a good day ▲ Collapse
| | | |
Gyula Erdész wrote:
Essentially, as giraffes are essentially horses...
Cheers,
Gyula
... slightly amusing but essentially nonsense.
Regards
Paul
| | | | Philomelius
Local time: 12:40
English to French
+ ...
TOPIC STARTER | It usually is | Dec 10, 2013 |
Essentially, as giraffes are essentially horses...
And whales are essentially very old dogs
| | | | | Not just nonsense | Dec 10, 2013 |
Gyula Erdész wrote:
Essentially, as giraffes are essentially horses...
this is not only essentially nonsense, it is wrong too, see:
The even-toed ungulates (Artiodactyla) are ungulates (hoofed animals) whose weight is borne about equally by the third and fourth toes, rather than mostly or entirely by the third as in odd-toed ungulates (perissodactyls), such as horses.
Artiodactyla comes from (Greek: ἄρτιος (ártios), "even", and δάκτυλος (dáktylos), "finger/toe"), so the name "even-toed" is a translation of the description.[1] This group includes pigs, peccaries, hippopotamuses, camels, llamas, chevrotains (mouse deer), deer, giraffes, pronghorn, antelopes, sheep, goats, and cattle. The group excludes whales (Cetacea) even though DNA sequence data indicate that they share a common ancestor, making the group paraphyletic. The phylogenetically accurate group is Cetartiodactyla (from Cetacea + Artiodactyla).
http://en.wikipedia.org/wiki/Even-toed_ungulate
| | |
|
|
|
Gyula Erdesz
Hungary
Local time: 12:40
Member (2009)
English to Hungarian
+ ...
SDL Support wrote: Gyula Erdész wrote:
Essentially, as giraffes are essentially horses...
Cheers,
Gyula ... slightly amusing but essentially nonsense. Regards Paul
Nonsense? Really?
Then could you please enlighten me on why other CAT tool developers struggle a lot with this format? Are they so much duller than your colleagues at SDL?
Trying to keep your market position with such practices is totally understandable for me. But please, please refrain from such hypocritical comments like "What do you find so hard about this?". It is simply not fair.
Kind regards,
Gyula
| | | |
Gyula Erdész wrote:
Then could you please enlighten me on why other CAT tool developers struggle a lot with this format? Are they so much duller than your colleagues at SDL?
Trying to keep your market position with such practices is totally understandable for me. But please, please refrain from such hypocritical comments like "What do you find so hard about this?". It is simply not fair.
... if you can explain who is struggling with this and why then perhaps I can help? SDLXLIFF is fully compliant with the XLIFF standard and the only reason we have SDL at the front is for recognition. Probably the same as Kilgray using mq at the front of theirs. I know Kilgray, Atril and others all claim to support SDLXLIFF already.
Certainly I have no idea at all what practice you are referring to but unless you give me some concrete examples it’s a bit of a one sided conversation.
Regards
Paul
| | | | Gyula Erdesz
Hungary
Local time: 12:40
Member (2009)
English to Hungarian
+ ...
SDL Support wrote:
unless you give me some concrete examples it’s a bit of a one sided conversation.
With pleasure:
Memsource Cloud:
http://wiki.memsource.com/wiki/SDLXLIFF
"While SDLXLIFF files can be imported into a MemSource project, we typically do not advise our customers to translate these formats in MemSource as their standard practice. The reason is that these formats are proprietary and can be best translated by SDL software that has been designed for it. There may always be minor or even major incompatibilities when translating Trados bilingual files in a non-Trados software."
Wordfast Pro:
http://www.wordfast.com/support_release_notes.html
"Added SDLXLIFF filter to roundtrip SDLXLIFF files"
Emphasis on roundtrip. As a software delevoper, why do you need to roundtrip something that is fully clear, open and accessible?
Kind regards,
Gyula
| | | |
... here’s my take on these that are not really the examples I wanted.
Wordfast
They have added support for SDLXLIFF. Where does this demonstrate a problem? They mention roundtrip... you roundtrip DOC files, XLSX files... nothing odd about this as far as I can see. Roundtrip simply means you open the source (SDLXLIFF in this case), translate it and save it again.
MemSource Cloud
This also non-specific and I think was written to provide some cover for an... See more ... here’s my take on these that are not really the examples I wanted.
Wordfast
They have added support for SDLXLIFF. Where does this demonstrate a problem? They mention roundtrip... you roundtrip DOC files, XLSX files... nothing odd about this as far as I can see. Roundtrip simply means you open the source (SDLXLIFF in this case), translate it and save it again.
MemSource Cloud
This also non-specific and I think was written to provide some cover for any problems that do occur through translating SDLXLIFF files. This doesn’t mean that we have made it difficult. SDLXLIFF files, MQXLIFF files and MXLIFF files are all compliant XLIFF as far as I know. The reason anyone would make a statement like this is because the XLIFF standard allows for some extensibility. This means that tool vendors can enhance the value their own customers get from the information held within the XLIFF.
So for anyone who needs to read an XLIFF like this the task, at a high level, is twofold. First, they extract the translatable text (this should be simple) and then the decision is theirs on how far they wish to support the extensible parts. It’s not essential as they really only have to maintain the content if they can’t use it in the tool they have. So for example, if a particular tool cannot use all the statuses such as Draft, Translated, Reviewed, Signed Off, then just make sure that they are not lost. This doesn't affect your ability to handle the files.
I don’t really think you are demonstrating a problem here, but what I do thin you are doing is demonstrating a problem we have suffered with for some time. This is that many users just believe that we are proprietary and are making life harder for everyone else, and they believe it because they read it in the forums based on unqualified comments. I don't mean this to pick on you in particular, but I do think this is a problem.
I think SDL have never been so open, and in addition we publish an extensive SDK and API that allows developers to do more with our software than ever before, and probably more than any other commercial vendor.
But I think by now we are way off topic. many apologies to the OP. My original question, which seems to have caused some offence (and it was not intended) was why the OP considered that SDL make it so hard? That comment is quite unfounded in my opinion and unfortunately the first reaction of many people is to accept this as read and sympathise because of bad old SDL.
Regards
Paul
[Edited at 2013-12-10 09:46 GMT] ▲ Collapse
| | |
|
|
|
Gyula Erdesz
Hungary
Local time: 12:40
Member (2009)
English to Hungarian
+ ...
| My two cents | Dec 10, 2013 |
Dear Paul,
Every coin have two sides.
Each and every proprietary file format is an unnecessary constraint for us, freelance translators. If you stick to the tool of your own, this constraint means extra work with CAT hopping, conversion and debugging. Pure annoyance.
I do not like SDL Studio 2011 / 2014 because it is slow and Multiterm is unstable. For me. On my PC. For this reason I tried out practically all the CAT tools available on the market and base... See more Dear Paul,
Every coin have two sides.
Each and every proprietary file format is an unnecessary constraint for us, freelance translators. If you stick to the tool of your own, this constraint means extra work with CAT hopping, conversion and debugging. Pure annoyance.
I do not like SDL Studio 2011 / 2014 because it is slow and Multiterm is unstable. For me. On my PC. For this reason I tried out practically all the CAT tools available on the market and based on on my personal experience, .sdlxliff file does mean (or at least can cause) difficulties for the majorities of the software. Sure, Deja Vu, Wordfast etc. can state that the are fully compatible with .sdlxliff, but believe me, they are not.
To recap the situation:
You are really kind and committed to .xliff standard and publish all information about your proprietary .sdlxliff format. But for some miraculous reasons other CAT tool developers still not able to produce the filters needed to handle such files error free.
And this means uncertainty and extra work for us, freelancers.
Sorry for being off-topic but I really wanted to tell you this.
Kind regards,
Gyula ▲ Collapse
| | | | | Two sides of the coin? | Dec 10, 2013 |
Gyula Erdész wrote:
Every coin have two sides.
Each and every proprietary file format is an unnecessary constraint for us, freelance translators. If you stick to the tool of your own, this constraint means extra work with CAT hopping, conversion and debugging. Pure annoyance.
I won’t disagree with this. The same problem works all ways and not just with SDL. If someone who does like Studio receives files from Wordfast, memsource or memoQ then the same problems abound. They almost always mean that you need to have a copy of the originating tool anyway, or a customer who is happy to finish them off.
But you are still using this word proprietary and it’s very misleading. Proprietary file formats mean that the provider either encodes the files in some way that you you need the originating tool to use them, or that they are licensed to protect the way they can be used. Considering we, and others, use the XLIFF standard I don't think these filetypes can be considered proprietary. The problem is simply that the standard is extensible and this allows vendors to provide benefits for users staying within the same toolset, but potentially additional work when you switch between tools. In some cases these extensions are of no value to other tools anyway so they only need to be retained in the file!
There are basically three ways to handle the problem I think.
1. Use the same tool the file originated in, or at least have a copy to finish it off
2. All vendors publish an API/SDK so that specific filetypes can be added to support the peculiarities of each one by the vendors who understand their own requirements better.
3. A new, simplified standard for file exchange that focuses on some nailed down rules (such as the XLIFF:doc) is supported and created by all tools
We already support the first two and I favour the second simply because it means any vendor who wants to can help to ensure that some of the extensible benefits can be maintained, or potentially even reused, and the customer can benefit more from their own choice of tool.
But I can see the benefits of the third approach as well. Particularly if the customer is more interested in ensuring balanced support for their translators than they are for themselves.
It’s an interesting discussion, and it is not only a problem related to SDL, and it’s certainly not because we are proprietary or determined to make life harder for everyone else. Our interest is in trying to bring as many benefits to our own users as we can, but at the same time ensuring we adhere to the applicable standard for the bilingual formats we work with and maintaining a platform that supports the development of anything else by any interested developer.
So I imagine once XLIFF:doc starts to become commonplace, if it becomes commonplace, that we’ll see someone adding support for this too... so I think we really support all three solutions already.
That would be my two cents.
Regards
Paul
| | | | Gyula Erdesz
Hungary
Local time: 12:40
Member (2009)
English to Hungarian
+ ...
Hello Paul,
Thank you very much for your detailed answer. It explains your current situation & aims quite well.
Best regards,
Gyula
| | | | | Pages in topic: < [1 2 3] > | To report site rules violations or get help, contact a site moderator: You can also contact site staff by submitting a support request » Free, online CAT tool looking for beta testers | Protemos translation business management system | Create your account in minutes, and start working! 3-month trial for agencies, and free for freelancers!
The system lets you keep client/vendor database, with contacts and rates, manage projects and assign jobs to vendors, issue invoices, track payments, store and manage project files, generate business reports on turnover profit per client/manager etc.
More info » |
| | Trados Studio 2022 Freelance | The leading translation software used by over 270,000 translators.
Designed with your feedback in mind, Trados Studio 2022 delivers an unrivalled, powerful desktop
and cloud solution, empowering you to work in the most efficient and cost-effective way.
More info » |
|
| | | | X Sign in to your ProZ.com account... | | | | | |
Login to reply/comment 
Translation news related to CAT tools
