![]() ![]() Terminology can be shared with OmegaT via tab-delimited text files with three column (source, target and additional info). I did notice in my brief tests that subsegment matches from a TMX file were displayed in one of the panes on the right of the screen this was very helpful. If one accidentally continues to the next segment, the automatic markers will make it easier to find the error. Perhaps this will force some people to stop and think about a match before blindly continuing to the next segment. Fuzzy matches are processed a little differently in OmegaT, for example by putting before a segment which is automatically inserted. While the matching may not be optimal this way, so the translator may have to work a little harder, this is not necessarily a bad thing. TM content can be exported from DVX or Trados as TMX and placed in the TM folder of the OmegaT project. Since DVX can process all Trados formats if they are pre-segmented, this method also enables OmegaT to process any Trados files with a guarantee of 100% compatibility. The RTF external view table is re-imported to the DVX project.After the target file is exported, the table column in it is copied to the target text column of the original RTF external view table.The ODT document is translated normally in OmegaT with care taken not to damage the codes enclosed in curly brackets (example: ).The OmegaT user opens the RTF external view and copies the source column to a new OpenOffice ODT document.Export an "external view" as an RTF table with all segments or whatever portion you want to have worked on by the OmegaT user.It's quite simple, really, if you have access to DVX Workgroup. I suspect there may be some issues here, because I used to use OpenOffice to clean up trash codes in MS Word and RTF files, and sometimes the formatting got messed up.Īfter a several discussions with Marc Prior, the project coordinator for OmegaT, one workflow which would give both of the aforementioned free tools the ability to work on projects involving any format which can be processed by Déjà Vu X or SDL Trados became apparent. The usual workflow for MS Word documents with OmegaT, for example, involves conversion to ODT format for translation and subsequent re-conversion. One "knockout criterion" for me was that this software allows the translator to translate only a limited number of formats, not including many of the most popular ones. I've always been rather skeptical of tools like these, especially after discussions with developers who have confirmed some of the limitations. Not infrequently, fire-breathing Open Source fanatics or even calmer souls who prefer free software to commercial stuff that would probably increase their efficiency and certainly improve their marketability make a case for tools like Metatexis or OmegaT. Perhaps you could edit the TMX to remove the BOM and try importing to TRADOS again.Discussions of CAT tools never end in the online forums and elsewhere, and there are often heated arguments about which tools are best, whether claims of compatibility are to be taken seriously, etc. Here is a link to more (often confusing) info: Various listmembers then recommended their favourite free textĮditors, eg, UniPad, BBEdit v8 on Mac OSX, etc that can add/remove the BOM. So far I had no luck with this method on other TMs. This is a major step forward as all other Wordfast TMs converted with OOo did not work in UTF-8, and any other encoding made Umlauts disappear. Surprisingly enough, the WF TM worked after I saved it without a BOM in UTF-8, with all characters appearing as they should. Since I was having problems with one of my Wordfast TMs, I downloaded an editor that converts between different encodings and also gives me the choice to set a BOM or not. It seems that Windows Notepad is one of these editors that puts a BOM at the beginning of a UTF-8 encoded file, and you can't influence that. This is from the original post on that list from Jan 19:Ī couple of days ago I stumbled over an article that dealt with theīyte order mark issue in some UTF-8 encoded XML files and the fact that some text editors add a BOM and others don't. There is no standard, it seems, and some text editors include it for both UTF8 and UTF-16 files, other only for UTF-16. ![]() Involved discussion on the OmegaT Yahoo Group just recently about this. ("Line 1, Offset 1"), it could be due to a conflict between the CATsĪbout whether to expect a byte order mark. Since this error refers to the very first character in the file Subject: Re: Problem exporting WF TM (tmx) back to Trados 6.5 ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |