THE PERILS OF CSV

WARNING: Highly technical content. Hit the back button, if you're faint of heart. ;-)

Some translators will cringe away from the technicalities of their job. But if you work with CAT tools, then by definition you are prepared to work with many different file formats. And there is no getting away from the technical side of this job.

Here's my experience with a certain CSV. It was clearly exported from a content management system. Only some columns were intended for translation, and one of these columns contained very lengthy strings of text with HTML and CSS tags.

What is the first thing that comes to mind when you want to view a CSV file and prepare it for translation in a CAT tool such as SDL Studio? Excel, of course. But then it turns out that the wizard for importing a CSV file is far from intuitive. You have to set the content type for each column one by one. For comparison, in LibreOffice Calc you can select all columns in the wizard and change the content type in one go.

That is one hurdle behind us, now the excel file can be imported into Studio, an analysis can be done and a quote sent to the client. A few days later the quote is accepted and some days later you get to work.

But then, a surprise. You find that text and tags from the longest column is often truncated. After some digging you find out that even though the latest Excel can hold vast amounts of data in a cell, it will most likely truncate the text at 1024 characters or so.

So when you're about to start working on the job, you find out that your quote was undervalued and there is more text to translate than you thought, and the client won't accept a new quote.

But you need a workaround. So your idea is to copy each column to a separate text file and process these files in Studio, because you know how to handle tags in text files in Studio. Wrong again, and on two levels. First, Studio will assume that these files are encoded in the default code page for your locale, for Poland it is windows-1250. Converting the CSV file to windows-1250 is not a good idea, because then some technical characters, such as Ø, will be lost. And the segmentation in the text file with tags will be horrible, for example, that one lengthy cell from the CSV will be crammed into one segment in Studio anyway.

So, finally the columns without tags were imported as ODS sheets (that is the LibreOffice Calc format), and the columns with tags were converted into ‘fake’ HTML files (with HEAD, META encoding [utf-8, by the way], and BODY tags) and imported in these formats. Only then the segmentation of the ‘tag soup’ content was bearable.

And only then was I able to start my main line of work, that is translation.

Phew. Lesson learned.



Comments

Post a Comment

Popular posts from this blog

Python 3 script for Deepl Translator Pro Among the MT (machine translation) providers Deepl is the new kid on the block, but it has been making waves ever since it appeared. Frankly speaking, as soon as I found out how good the Deepl MT is, I actually abandoned Google Translate. If I am to pay for a service, I'll pay for the one which delivers better results. Before Deepl announced the paid Pro service, there was (and still is) the free Python module called pydeepl. It used to work until recently, but the ‘backdoor’ making it possible to programmatically get free translations in the era of the paid service has recently been plugged. (For the record, I subscribed to the paid service as soon as it appeared). There also is a Deepl Translator plugin for SDL Trados Studio. It is quite simple and almost no settings, except for the API key, can be entered. My Python script for pydeepl was more sophisticated, for example I added a replacement table for cases where I did not like Deep
Read more
Image
 Skrypty w Pythonie Ułatwiające wypełnianie JPK_VAT7M od jpklibre (Oj dawno nic nie pisałem na blogu!) Do niedawna robiłem JPK za pomocą arkusza w Excelu, ale na nowym komputerze Excel 64-bitowy, więc arkusz nie działa. Dlaczego – nie będę się rozpisywać. Pora na rozwiązanie uniwersalne, które będzie działać niezależnie od systemu operacyjnego – skoroszyt  jpklibre , bo komputerów z Windowsem mam 1, a z systemem Linux – kilka. Można oczywiście wypełnić arkusz ręcznie, ale to jest mozolne. Można też poddać w wątpliwość sens arkuszy, gdy pliki JPK powinno generować oprogramowanie księgowe. Owszem, moje generuje, ale uparło się przy tym robić korekty, które nic nie mają wspólnego z rzeczywistością, więc robię sam - półautomatycznie. Żeby nie wypełniać jpklibre całkowicie ręcznie, można skorzystać z rozwiązania Scriptforge, które dostępne jest "fabrycznie" dla LibreOffice Calc od wersji 7.3 LibreOffice. Trzeba tylko doinstalować rozszerzenie APSO , które ułatwi uruchamianie makr
Read more
Macros, scripts, coding In the early years of my freelancing I worked mostly in Microsoft Word. I either did not use any CAT tool or I used the free version of Wordfast (now called Wordfast Classic) which is a set of macros in itself. I was looking for ways to make my tedious work of translating in Microsoft Word a bit easier. Soon I found out about macros. Initially I created them by recording, then I learned more about coding them. Now, though most of my translation work is done outside of Microsoft Word, in CAT tools, I still have most of the macros I created more than 10 years ago. Many of them fell into disuse, but there is one that I use regularly when I need to do some work in Word. It is the macro I called ‘TextFieldFit’. When I draw a text box, I run the macro to reduce the inner margins, remove the border around the box and reduce the font size. I use text boxes to translate drawings that did not get imported into my preferred CAT tool, the SDL Trados Studio. I
Read more