Start a new topic

REQ: Bilingual files, next round

This is not my favorite subject, and we got it somehow covered here, here, here and here. One of the (not at all convincing) arguments of having the whole table eco-unfriendly cluttered with color is that it would be eye-friendly instead of white.


However, when exporting external file formats with comments, I stumbeld upon this:

image


A yellow notes' column? I do not think this is eye-friendly. This is Smartcat XLIFF, where the state is not recognized/stored in CT, maybe this is the culprit. If this yellow is only due to the fact of not having checked the segment: Why is a checked segment dark green and a translated segment only partially yellow?


For now, the colors of bilingual files are not meant for printing. This functionality may be added in the future. Yellow color is traditionally related with notes. It is IMO quite friendly. If it was so unfriendly the giant companies would not make their notes and stickers yellow in the software or OS.


As for eco-friendliness argument, it is a bit amusing in this context when you print wasting paper instead of reading on a tablet or laptop. Colors are a matter of taste.

> If it was so unfriendly the giant companies would not make their notes and stickers yellow in the software or OS.

Sure, but they put it only on single notes, not on whole columns. The yellow color would be great and okay if it was only for the segments containing notes, bit not for all segments (the alertness effect gets totally lost). And indeed when having a native project with confirmed segments the whole column is (= all columns are) green. This is simply inconsistent anyway.


As these colors are programmed, it would be nice to have at least an optional two-color-print. To print black and white the CT output is useless, as the green is so dark that the result is bad.


> As for eco-friendliness argument, it is a bit amusing in this context when you print wasting paper instead of reading on a tablet or laptop.


No, it is a matter of quality. I do not print out every job*, but many, as it rises quality remarkably. You will have a different look if not working onscreen. Some physiological or neurological studies (1, 2, 3) have already proven that. Same for those practizing it. More quality means to qualify for better clients means less stress and more sales. It's worth it. From this point of view it is eco-friendlier to print out some pages than wasting resources by more rework time with people and running computers involved.


* Of course I do not print out rush jobs, short jobs or jobs with not so strict clients where I know or where I am told that a reviewer will have a second look.


Just from one of the articles above:

Why not have a hardcore one-language proofread export, with only the target language set in Courier New and with double spaced lines (I am not talking of Export to text? Would be great to round up already (bilingually) proofread texts.

There are many high profile texts in the industray that are proofread two or more times before getting published.

Here again, CafeTran could make the difference.
Login to post a comment