As a rule, tables are creatures of habit. When you create a table, it usually does what you wanted to do, that is, if you are working on a Hebrew document and you create a table, it will usually be a right-to-left table, while, if you’re working on an English document and you create a table, it will usually be a left-to-right table.
When you use CAT tools to translate a file and that file contains tables, the CAT tool will automatically flip the tables as you translates them. If for some reason, the tables are flipped around in the original document, they will also be in the wrong direction in the translated document, although they will look correct.
An important thing to understand is that the direction of the table does not affect the text direction, it just affects the behavior of the table itself.
The table below is a table that has been correctly created in a Hebrew document, as you can see from the little box with a cross (top right hand side), and from the symbols on the left-hand side of the table which are end-of-cell marks.
The table marker will always show you the table direction: if it is on the right-hand side of the table, the table is a right-to-left table and vice versa.
The table marker will always show if you’re in a table, the end-of-cell mark will only show if you work with hidden formatting symbols showing (see below).
The table below is the same table as above after it has been converted from a PDF file to a word file by ABBYY.
ABBYY normally converts Hebrew PDF files very well, but because it does not actually work with Hebrew, it treats all text as running from left to right and thus any table it converts will become a left-to-right table. As you can see, the table looks right, but it is the wrong way round. This table, when translated, will be the wrong way round in English as well, as shown below.
What happens when the table is the wrong way round is that if, say, you want to copy numbers into it from another table that is left-to-right, the columns you are trying to copy-paste will go completely awry, because the receiving table is actually working in the opposite direction. You can find out very easily if the table is in the right direction – all you need to do is place your cursor in one cell and press TAB. If the table is Left-to-right the cursor will jump to the cell to the right of the one it was in, if it is right-to-left the cursor will jump to the cell to the left of the one it was in.
Admittedly, you can leave the table as it is, because it looks correct, but if you need to work with them, if you need to make changes, etc., this is not really an option. So what do you do?
Well, what I do is, I flip the table so it is a left-to-right table, but then I have the text on the wrong side and the number columns are also the wrong way. Not a problem – a bit laborious maybe, but fairly easy.
First of all, if there are merged cells as in the table above (the cell with the text (Unaudited)), I split the merged cell into two cells and I make sure that they are identical to the rest of the column.
Then I move each column to the left of the text column, one by one, starting with the one nearest the text column. I move each column to just inside the end-of-cell mark and leave it. You do that by selecting the column and then keeping the left mouse button pressed, you drag the entire column over to the right hand side of the text column.
The table after the first column has been moved.
The table after the second column has been moved.
The table after the last column has been moved.
And there you have a left-to-right table, looking correct and behaving correctly. All you need to do now, is re-merge the (Unaudited) cells.
True, if you have forty or eighty pages of tables running in the wrong direction the thought of having to go through this process forty or eighty times is very depressing, but I assure you after the first few times, you’ll notice it gets easier and faster all the time.