Tuesday, September 21, 2010
It worked. In just a few minutes I could see TIFF files for the faxes on the account area on the web site. A few minutes later I received copies of the faxes as e-mail attachments.
I haven't looked into the security issues with the site yet; I'll probably be appalled when I do. Maybe not. It's an interesting application and one for which I can see some integration possibilities with other applications I use, such as LSP.net's Online Translation Manager. I can see this being useful when I'm travelling or to save me the trouble of re-scanning faxes for OCR purposes. I used to use a fax modem many years ago for similar reasons, but faxes have become such a rare thing in my business over the past decade that I haven't bothered about such solutions in a long time.
Thursday, September 16, 2010
This overview shows the behavior of the Java properties file filter in memoQ version 4.2.20 and how to configure and work with it to manage projects with a small or large number of files successfully. In the current version of memoQ (unlike Déjà Vu, for example), the output format must be selected when applying the import filter. It is currently not possible to change the output encoding "on the fly".
Default settings for the filter
The current default settings for the filter will often not lead to the desired result, which is an output file with the same escape coding found in the original properties file. (An example for the German letter "Ü" is marked with a red box.) An example of the output with these default settings is show below.
Output of a French translation with the default settings for the Java properties filter
This looks good, but it's useless. The file would have to be converted using an external utility like the Rainbow tools. The problem here is that the wrong output format is used for the translated file. The proper settings are show below.
Set the output encodig to US ASCII
This screenshot actually specifies the input encoding incorrectly (it's an ANSI file I'm importing), but that doesn't matter in this case. because the preview displays the input text correctly. The important thing here is that the output is set to US ASCII, which forces the Unicode escape coding for all the "special" characters used in the language (i.e. those which are beyond the character set of US ASCII).
Output of the correctly escaped Java properties file
The example above shows the text as it is required in a Java properties file using escape coding. The same procedure applies to other languages, such as Greek. The memoQ translation and editing enviroment displays these escaped characters in a proper, readable format which allows you to work on the translation without undue stress. Examples of the view in the various memoQ environments and bilingual output formats are show below.
View in the memoQ application's translation and editing environment
Here all the escaped characters are displayed in a legible manner as they should be. Conversion to escaped ASCII text occurs only when the translation is exported as a Java properties file.
View in memoQ's Trados-compatible bilingual DOC export
The Trados-compatible bilingual format from memoQ allows the content to be translated using the TWB macros of Trados Classic or using other tools such as Wordfast Classic or Anaphraseus. Here the text is also displayed in a legible format for working. Tags are displayed in red and must not be altered by the translator.
View in memoQ's multi-column RTF table export
This view is also interesting because it incorporates the memoQ comment fields, which in the case of a Java properties file contains the key of the key/value pair. This is useful context if you need to ask questions of the programmers.
Thursday, September 02, 2010
- a large number of projects for a team of two which required better coordination of schedules;
- responsibilities for portions of shared projects needed better definition (after a few incidents of accidental overlap in rushed projects with many files);
- access to the project management and invoicing functions by multiple persons was needed so that everything wasn't bottlenecked by my busy schedule;
- better data backup was needed after a hard drive with far more than a month's worth of unbilled work died unexpectedly and proved unrecoverable (very, very expensive);
- more secure data transmission (for receiving and delivering project files) was required after various half-baked encryption schemes several clients wanted proved unreliable;
- more reliable delivery of translations had long been required – several incidents each year occur where e-mail is delayed for hours, days, even weeks;
- access to project information was often required when we were out of the office, traveling, etc.;
- a better “filing solution” was needed for compliance with the legal requirements for retaining project-relevant documents such as e-mail, NDAs, master agreements, etc.