Pages in topic:   < [1 2 3 4 5 6 7 8 9 10 11] >
TMLookup
Thread poster: FarkasAndras
FarkasAndras
FarkasAndras  Identity Verified
Local time: 23:38
English to Hungarian
+ ...
TOPIC STARTER
Way off Jan 11, 2016

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
Michael Beijer  Identity Verified
United Kingdom
Local time: 22:38
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
Michael Beijer  Identity Verified
United Kingdom
Local time: 22:38
Member (2009)
Dutch to English
+ ...
problem importing any TMXs created by Felix Jan 16, 2016



https://dl.dropboxusercontent.com/u/6802597/TMXs/test-(exported-from-Felix)(won't-import-into-TMLookup).tmx

https://dl.dropboxusercontent.com/u/6802597/TMXs/test-(Felix-TMX,-exported-from-Olifant)(will-import-into-TMLookup).tmx

Any idea what is causing this?


 
FarkasAndras
FarkasAndras  Identity Verified
Local time: 23:38
English to Hungarian
+ ...
TOPIC STARTER
Done Jan 16, 2016

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
FarkasAndras  Identity Verified
Local time: 23:38
English to Hungarian
+ ...
TOPIC STARTER
Possibly Jan 16, 2016

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
Michael Beijer  Identity Verified
United Kingdom
Local time: 22:38
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
FarkasAndras  Identity Verified
Local time: 23:38
English to Hungarian
+ ...
TOPIC STARTER
1.54 Jan 16, 2016

Fixed the TMX import bug and added a checkbox to filter out half-empty segments during imports:
https://dl.dropboxusercontent.com/u/16377950/TMLookup_1.54_win.zip


 
Michael Beijer
Michael Beijer  Identity Verified
United Kingdom
Local time: 22:38
Member (2009)
Dutch to English
+ ...
Thanks! Jan 17, 2016

FarkasAndras wrote:

Fixed the TMX import bug and added a checkbox to filter out half-empty segments during imports:
https://dl.dropboxusercontent.com/u/16377950/TMLookup_1.54_win.zip


 
Michael Beijer
Michael Beijer  Identity Verified
United Kingdom
Local time: 22:38
Member (2009)
Dutch to English
+ ...
@András: Jan 26, 2016

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
FarkasAndras  Identity Verified
Local time: 23:38
English to Hungarian
+ ...
TOPIC STARTER
FTS5 Jan 26, 2016

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
FarkasAndras  Identity Verified
Local time: 23:38
English to Hungarian
+ ...
TOPIC STARTER
Manners Jan 26, 2016

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
Michael Beijer  Identity Verified
United Kingdom
Local time: 22:38
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
FarkasAndras  Identity Verified
Local time: 23:38
English to Hungarian
+ ...
TOPIC STARTER
me too Jan 26, 2016

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
Michael Beijer  Identity Verified
United Kingdom
Local time: 22:38
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
FarkasAndras  Identity Verified
Local time: 23:38
English to Hungarian
+ ...
TOPIC STARTER
Sure Feb 2, 2016

It looks simple enough to do. All I need to work out is whether it uses character references in addition to &lt; and &gt;. Probably &amp; 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







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 »
CafeTran Espresso
You've never met a CAT tool this clever!

Translate faster & easier, using a sophisticated CAT tool built by a translator / developer. Accept jobs from clients who use Trados, MemoQ, Wordfast & major CAT tools. Download and start using CafeTran Espresso -- for free

Buy now! »