Pages in topic: < [1 2 3 4 5 6 7 8 9 10 11] > | TMLookup Thread poster: FarkasAndras
| FarkasAndras Local time: 11:41 English to Hungarian + ... TOPIC STARTER
Traducendo Co. Ltd wrote: Hi everyone and sorry for the offtopic. One of my translators candidely decided to translate a huge file using Virtaal and now she's not able to export the file in target format (.docx) nor to provide me with a tmx. I have been going through forums and websites, and I have checked the virtaal help pages to find a solution yet nothing popped out. This forum seems the closest to my issue. Maybe any of you Virtaal users can help me to get .docx file from the .xliff the translator sent me? Unfortunately Trados 2011 and 2014 seem to be able to open the xliff and my client is expecting the delivery within few days. Please let me know if there is a solution!!! Thanks a lot This is not even remotely related to the topic of TMLookup... it would have been a better fit for a Virtaal forum/thread or a new thread of its own. Anyway, if you have exhausted Virtaal's support/troubleshooting options and there is really no hope of generating a target file from Virtaal, you should convert that xliff into a bilingual format that Studio can handle (tabbed txt or tmx), import it into Studio as a TM, and translate the original docx with that TM. The last step will probably require some fiddling and possibly the retranslation of some segments but it shouldn't be too bad. If you post the xliff here I will have a look at it. You should also try to import the xliff into any other CAT tool you have access to. If you can import it, export a tmx and you're in business. Xbench could also work for converting the xliff into some manageable format. If studio failed to import it the file might be corrupted but you gave no info on what happened so I'm shooting in the dark. | | | Michael Beijer United Kingdom Local time: 10:41 Member (2009) Dutch to English + ... feature request! | Jan 16, 2016 |
The following functions would be cool: • Remove entries with empty source • Remove entries with empty target | | | Michael Beijer United Kingdom Local time: 10:41 Member (2009) Dutch to English + ... | FarkasAndras Local time: 11:41 English to Hungarian + ... TOPIC STARTER
Michael Beijer wrote: Any idea what is causing this? This is caused by the unusual tmx generated by felix and the half-assed tmx processing done by TMLookup. I'll fix it in the next release. Boring technical details: TML doesn't properly parse TMX because I don't know much about xml parsers, and the only available parser I found that was specifically written for tmx is crap. So I just hacked together some regex code that extracts the relevant parts from TMX, but there's always the chance for screwups with a solution like that if the xml/tmx is not exactly how you expected it. I think I noted this here and asked for testing. Anyway, my code expects the tuv tag to end right after the language is declared, like so: a <tuv xml:lang="NL">. Felix tacks on the creationdate and importing the tmx fails because TMLookup can't tell what the languages are. Olifant removes the creationdate from one of the two langs, so at least one is recognized and the import proceeds (with a warning message). I now fixed the bug and added some primitive error handling so that the import can continue even if the languages are not recognized. Nobody reported this bug so far, which means that felix might be the only tool that adds something in the tuv tag after the language code. Most tools add the creationdate in the tu (segment level) tag, which makes a lot more sense than adding the creationdate twice into every segment, into each tuv (language level) tag. Not sure if what felix does is just a little unusual or wrong, but it doesn't matter much. | |
|
|
FarkasAndras Local time: 11:41 English to Hungarian + ... TOPIC STARTER
Michael Beijer wrote: The following functions would be cool: • Remove entries with empty source • Remove entries with empty target I considered ignoring segments with empty source or target during import. I decided against it because sometimes these segments can be useful (if the empty field is caused by misalignment, you can use the see context feature to see the segment before/after and find the missing text). An option to delete them after importing or a switch to skip them during importing could be useful. The latter would be easier to implement and less messy. Wouldn't do much for existing DBs but c'est la vie. | | | Michael Beijer United Kingdom Local time: 10:41 Member (2009) Dutch to English + ... cool, thanks! | Jan 16, 2016 |
FarkasAndras wrote: Michael Beijer wrote: Any idea what is causing this? This is caused by the unusual tmx generated by felix and the half-assed tmx processing done by TMLookup. I'll fix it in the next release. Boring technical details: TML doesn't properly parse TMX because I don't know much about xml parsers, and the only available parser I found that was specifically written for tmx is crap. So I just hacked together some regex code that extracts the relevant parts from TMX, but there's always the chance for screwups with a solution like that if the xml/tmx is not exactly how you expected it. I think I noted this here and asked for testing. Anyway, my code expects the tuv tag to end right after the language is declared, like so: a . Felix tacks on the creationdate and importing the tmx fails because TMLookup can't tell what the languages are. Olifant removes the creationdate from one of the two langs, so at least one is recognized and the import proceeds (with a warning message). I now fixed the bug and added some primitive error handling so that the import can continue even if the languages are not recognized. Nobody reported this bug so far, which means that felix might be the only tool that adds something in the tuv tag after the language code. Most tools add the creationdate in the tu (segment level) tag, which makes a lot more sense than adding the creationdate twice into every segment, into each tuv (language level) tag. Not sure if what felix does is just a little unusual or wrong, but it doesn't matter much. I'll ask him. TMX isn't the standard TM format in his tool (he has his own, special .ftm XML format), so maybe it was just an oversight. Michael edited to add: OK, just emailed Ryan (the developer of Felix), asking him about the tu/tuv issue. also made a quick screenshot showing what it looks like:
[Edited at 2016-01-17 11:29 GMT]
[Edited at 2016-01-17 11:29 GMT] | | | FarkasAndras Local time: 11:41 English to Hungarian + ... TOPIC STARTER | Michael Beijer United Kingdom Local time: 10:41 Member (2009) Dutch to English + ...
|
|
Michael Beijer United Kingdom Local time: 10:41 Member (2009) Dutch to English + ...
You mentioned somewhere, I can't remember where, that at some point in the future we will have to re-create our DBs. When will this be? Just planning ahead. | | | FarkasAndras Local time: 11:41 English to Hungarian + ... TOPIC STARTER
The change in internal db formats will happen if/when I swich TML over to FTS5. I wrote about what I expect from FTS5 a couple of times, on page 5&6 of this thread I think. FTS5 has already been released by the sqlite team, but it hasn't trickled down to DBD::SQLite, which is the implementation of SQLite that I use in TML. So it will probably take a month or two before I can get my hands on FTS5. Then I will have to see what it has to offer for TML and decide whether/when to make the switc... See more The change in internal db formats will happen if/when I swich TML over to FTS5. I wrote about what I expect from FTS5 a couple of times, on page 5&6 of this thread I think. FTS5 has already been released by the sqlite team, but it hasn't trickled down to DBD::SQLite, which is the implementation of SQLite that I use in TML. So it will probably take a month or two before I can get my hands on FTS5. Then I will have to see what it has to offer for TML and decide whether/when to make the switch. In short: my best guess is one to three months. Of course you can keep using the current version with your current DBs as long as you like. ▲ Collapse | | | FarkasAndras Local time: 11:41 English to Hungarian + ... TOPIC STARTER
FarkasAndras wrote: Traducendo Co. Ltd wrote: Hi everyone and sorry for the offtopic. One of my translators candidely decided to translate a huge file using Virtaal and now she's not able to export the file in target format (.docx) nor to provide me with a tmx. I have been going through forums and websites, and I have checked the virtaal help pages to find a solution yet nothing popped out. This forum seems the closest to my issue. Maybe any of you Virtaal users can help me to get .docx file from the .xliff the translator sent me? Unfortunately Trados 2011 and 2014 seem to be able to open the xliff and my client is expecting the delivery within few days. Please let me know if there is a solution!!! Thanks a lot This is not even remotely related to the topic of TMLookup... it would have been a better fit for a Virtaal forum/thread or a new thread of its own. Anyway, if you have exhausted Virtaal's support/troubleshooting options and there is really no hope of generating a target file from Virtaal, you should convert that xliff into a bilingual format that Studio can handle (tabbed txt or tmx), import it into Studio as a TM, and translate the original docx with that TM. The last step will probably require some fiddling and possibly the retranslation of some segments but it shouldn't be too bad. If you post the xliff here I will have a look at it. You should also try to import the xliff into any other CAT tool you have access to. If you can import it, export a tmx and you're in business. Xbench could also work for converting the xliff into some manageable format. If studio failed to import it the file might be corrupted but you gave no info on what happened so I'm shooting in the dark. You asked for help, I did my best to provide some. Don't you think it'd only be polite to check back in to say how you ended up handling the problem, and perhaps even to say thank you? | | | Michael Beijer United Kingdom Local time: 10:41 Member (2009) Dutch to English + ... Cool, thanks! | Jan 26, 2016 |
FarkasAndras wrote: The change in internal db formats will happen if/when I swich TML over to FTS5. I wrote about what I expect from FTS5 a couple of times, on page 5&6 of this thread I think. FTS5 has already been released by the sqlite team, but it hasn't trickled down to DBD::SQLite, which is the implementation of SQLite that I use in TML. So it will probably take a month or two before I can get my hands on FTS5. Then I will have to see what it has to offer for TML and decide whether/when to make the switch. In short: my best guess is one to three months. Of course you can keep using the current version with your current DBs as long as you like. Am currently trying to get my huge TMX collection in some semblance of order, for when the time comes to make a fresh start. | |
|
|
FarkasAndras Local time: 11:41 English to Hungarian + ... TOPIC STARTER
I know that feeling. I have a bunch of glossaries that I haven't really processed. Most of them are imported into multiterm but I never got around to getting any of them in TML. I only have my large reference TMs in TMLookup. Maybe I will get the glossaries imported sometime in the coming months, along with the iate glossary, which I haven't touched at all. I think I'll add tbx import while I'm at it to make it easy to import the iate dump without converting it to some other format first. | | | Michael Beijer United Kingdom Local time: 10:41 Member (2009) Dutch to English + ... Import Felix TMs? | Feb 2, 2016 |
FarkasAndras wrote: I know that feeling. I have a bunch of glossaries that I haven't really processed. Most of them are imported into multiterm but I never got around to getting any of them in TML. I only have my large reference TMs in TMLookup. Maybe I will get the glossaries imported sometime in the coming months, along with the iate glossary, which I haven't touched at all. I think I'll add tbx import while I'm at it to make it easy to import the iate dump without converting it to some other format first. These days, I keep all of my glossaries in my tlTerm termbase. See: http://www.proz.com/forum/internet_for_translators/297637-calling_all_tlterm_users_if_any.html I keep small, client glossaries in Felix glossaries. All TMs go in TMLookup. On the topic of Felix, I was wondering whether you would be able to do me a favour (if necessary for a small fee): do you think that you could maybe add the ability to import Felix TMs into TMLookup? They look like this: It's a bit of a pain in the ass having to constantly export a TMX of my project TMs after each job. | | | FarkasAndras Local time: 11:41 English to Hungarian + ... TOPIC STARTER
It looks simple enough to do. All I need to work out is whether it uses character references in addition to < and >. Probably & but there may be others. Email me a TM, preferably something with ampersands, apostrophes, quotes and a couple of accented letters thrown in and I'll have a look. If and when I get it done, you can paypal me a donation.
[Edited at 2016-02-02 12:43 GMT] | | | Pages in topic: < [1 2 3 4 5 6 7 8 9 10 11] > | To report site rules violations or get help, contact a site moderator: You can also contact site staff by submitting a support request » TMLookup Trados Business Manager Lite | Create customer quotes and invoices from within Trados Studio
Trados Business Manager Lite helps to simplify and speed up some of the daily tasks, such as invoicing and reporting, associated with running your freelance translation business.
More info » |
| 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 » |
|
| | | | X Sign in to your ProZ.com account... | | | | | |