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.
Thanks for sharing this! Being able to select the output encoding in memoQ is a great feature.
Depending on the system or workflow, translated *.properties files in UTF-8 encoding can also be okay. We have some clients who require UTF-8, and others who require US-ASCII.
Always a good idea to ask your client what they expect back and if they have no idea, to run a test with either encoding beforehand.
Thanks, Thomas - that's good to know. I haven't programmed Java in ten years, and so far I personally haven't had to translate properties files (and into English this won't be much of an issue I think), but several times now I've had to provide assistance for projects like this, because one of the last SDL Trados 2007 upgrades created a problem with this workflow, which technical staff were unable to sort out. The process also works nicely with Déjà Vu X, but I find the memoQ environment better for managing large numbers of files and keeping an overview of their status. The project that inspired this post involved actual translation with a bilingual DOC from memoQ using some older version of Trados with the TWB macros. All 97 files in a complex folder structure were "glued" together to make one file for the translator.ReplyDelete
I remember that upgrade. It caused the encoding of translated *.properties files to be always UTF-8, no matter the source encoding.ReplyDelete
SDL did a really nice job of not documenting the change and this got us into trouble in one project. They have changed this in the latest version I believe so the output encoding is always the same as the input encoding.
We now have automatic conversion flows set up to switch encodings on the fly using the Native-to-ASCII Converter in command line mode.
@Thomas: do you mean that you think the latest build of v8 (SDL Trados 2007) has fixed the issue, or do you mean that you think Studio 2009 is OK?ReplyDelete
Just tested it and output encoding is the same as the input encoding for both SDL Trados 2007 (8.6.3) and SDL Trados Studio (9.1.1264.0).ReplyDelete
I had already posted this suggestion http://ideas.sdltrados.com/ideas/detail.asp?i=2029 and I believe they were going to include such option in a future release of Studio.
Thanks for the pointer Thomas, I think we need a serious run through of ideas because you posted this idea well over a year ago, and we implemented this a long time ago. The facility is available for all file types not just Java Resource files, and also allows different outputs per file when you have merged them all into one SDLXLIFF at the start.
The encoding you select when performing Save Target As... has no effect whatsoever for the target *.properties files. The target encoding stays the same as the source.
Seems more logical to put an option under File Types > Java Resources to select target encoding.