Mac For Translators

Oracle JDK7 for OSX

2011-10-27T16:19:00.006+09:00

You remember when Apple said they would not maintain Java anymore ? That was just 12 months ago:

Java is dead! Long live Java? (on this blog)

I just noticed that Oracle released a new preview edition of JDK7 for OSX yesterday (b215).

http://jdk7.java.net/macportpreview/

I installed it and after changing my Java preferences (search for "Java Preferences" in SpotLight), I tried the preview version of OmegaT.

The result ?


54443: Info: OmegaT-2.5.0_1 (Thu Oct 27 15:05:55 JST 2011)  Locale en_US 
54443: Info: Java: Oracle Corporation ver. 1.7.0-ea, executed from '/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/Home/jre' (LOG_STARTUP_INFO)

It works !

No crash yet so I think I'll finish the current job with that new version of Java.

Be extra cautious though when you use preview versions of software. A bug can bite you in the middle of a job...

Update (a few hours later)
It works, but there are a few issues that make it not practical to work with this preview right now. I've reverted to Java 1.6 until Oracle delivers something closer to a release candidate :-)

Detailed information is here:

http://wikis.sun.com/display/OpenJDK/Mac+OS+X+Port+Project+Status

Update (a few days later)
Apple has just released a new update for Java 1.6 for Snow Leopard and Lion. Check software Update. The JDK7 port just released a new build: b217.

New fun to come with OmegaT 2.5...

2011-10-27T15:54:00.005+09:00

OmegaT 2.5, the preview version that you can get from:

https://sourceforge.net/projects/omegat/files/OmegaT%20-%20Latest/

includes a really nice new feature that, unfortunately, is not yet available for Mac users...

(Nov. 10 update: the latest version of the plugin works fine on Mac now)

If it is not, then you can rightly ask why bother mentioning it here at all ? Well, the answer is simple. It is kind of available, but because of an user interface design issue, the buttons that make it run are not available on Mac... This is going to be fixed real soon. In the meanwhile, get ready for...

A scripting interface to OmegaT's internals.

See the announcement here:

http://tech.groups.yahoo.com/group/OmegaT/message/22988

People who know what they are doing can already check this Java documentation page:

Scripting for the Java Platform

According to the scripting plugin source code, the possible languages for use in OmegaT are:

JavaScript
Jacl
NetRexx
Java
BML
VBScript
JScript
PerlScript
Perl
JPython
Jython
LotusScript
XSLT
Pnuts
BeanBasic
BeanShell
Ruby
JudoScript
Groovy
ObjectScript
Prolog
Rexx

There are already plenty of exchanges on the OmegaT mailing list regarding the scripting extension. Check this thread for example:

http://tech.groups.yahoo.com/group/OmegaT/message/23260

We'll have an announcement here when the feature works on Mac...

Dennis Ritchie and John McCarthy too...

2011-10-27T15:19:00.004+09:00

A few days after Jobs, Dennis Ritchie and John McCarthy passed away too, but that did not trigger international interest.

Dennis Ritchie is called the "father of C", C as in "C language". Everyone who's done a little bit of programming knows about the importance of C in the computing world.

http://en.wikipedia.org/wiki/C_(programming_language)

A few days after Ritchie, John McCarthy, the "father of Lisp" passed away too. Lisp is the language that was mostly used for artificial intelligence works "back then".

http://en.wikipedia.org/wiki/Lisp_(programming_language)

Lisp is 11 years older than C. Lisp was born in 1958 and C in 1969. But both languages are still commonly used in computing today...

Of course, both languages can be used on Macs. If you install the developer's tools that come with your DVD, you have access to a C compiler. Lisp, being a family of languages, requires to make a few choices (either get an ANSI standardized Lisp, or a Scheme, or a new Lisp like Clojure, that runs in Java etc.)

As for introductory books, "Land of Lisp" by Conrad Barski, M.D., from No Starch Press has been very well reviewed.

http://nostarch.com/lisp.htm

"Practical COmmon Lisp" by Peter Seibel from Apress is really nice too and sparked a renewed interest in the language. Plus, the PDF is freely available.

http://www.gigamonkeys.com/book

As for C, well, there are so many books about C programming that the only one I can think of is Kerninghan and Ritchie's "The C Programming Language, Second Edition" from Prentice Hall.

http://cm.bell-labs.com/cm/cs/cbook/

Objective-C is a strict super-set of C and is mostly known for being the language behind OSX applications.

A good introduction I found is "Programming in Objective-C" by Stephen G Kochan, from Pearson Education.

http://www.pearsonhighered.com/educator/product/Programming-in-ObjectiveC-3E/9780321711397.page

Of course, you can find plenty of free tutorial that can get you started in both languages.

Programming is fun and if it is not already the case, you should really give it a try.

Steve Jobs passed away

2011-10-06T12:42:00.001+09:00

It's going to be analyzed all over the world. Daringfireball linked to Job's Commencement Address in 2005. Here it is:

'You've got to find what you love,' Jobs says

Virtaal running on Mac ! Part II

2011-05-19T09:33:00.001+09:00

After the previous post, it appeared that Virtaal has problems with my configuration. Some testing and a few mails later here is a new announcement from the Virtaal team:

From: Dwayne Bailey
Date: 19 mai 2011 08:40:17 UTC+09:00
To: translate-devel@lists.sourceforge.net
Subject: [Translate-devel] Mac builds for Virtaal 0.7.0 rc1

You can get Mac OS X builds for Virtaal 0.7.0 rc1 here:
http://translate.sourceforge.net/snapshots/virtaal-0.7.0-rc1/Virtaal-Intel-0.7.0-rc1-1.dmg

Fixes since the beta 5 for Mac:
* The build uses its own Python (should solve your problem JC)
* Spell checking works - like Windows builds we download the spell checkers
* TM server is now running

Issues:
* We get a solid hang with some keyboard shortcuts e.g. Ctrl-W to close
the translation file. Navigation seems to work
* The installer is massive 43M, we'll put it on diet when we've got
stable builds
* The keyboard shortcuts are still mapped to Linux/Windows and haven't
been remapped to Mac
* Doesn't seem to work at all on 10.5 (Leopard) - well it does start but
you can't open anything
* Pango is still messing up Arabic

Basically Virtaal launches properly now. Welcome to the world of Mac Virtaal !

(Update: rc1-1 still had problems but rc1-2 worked fine. Check the snapshots located here to get the latest file: http://translate.sourceforge.net/snapshots/)

Virtaal running on Mac !

2011-05-15T12:40:00.000+09:00

From Dwayne Bailey, on the Translate Toolkit development list:

Hi Virtaalers,

I've just got Virtaal running on a Mac, in a bundle and in a disk image.

It needs a testers love so please head over here and get your disk image
http://translate.sourceforge.net/snapshots/virtaal-0.7.0-beta5/Virtaal-Intel-0.7.0-beta5.dmg

I'd love to hear your feedback

To install:
1) Download
2) Click on the disk image
3) Either drag Virtaal to your applications folder or run it directly
from the folder

Testing:
1) Try to translate things, looking around is great but real work brings
out the bugs
2) Report any bugs at bugs.locamotion.org

What works:
* The file menu is integrated like a Mac app
* Translating works
* TM and MT

What doesn't work... yet:
* Spell checking - we'll probably need to use the approach we're doing
in Windows to download
* The menu appears in the application window
* No fancy installer
* Keybindings are not Cmd+ but still Ctrl+ - some don't work like
pasting placeables.

Comments on the blog

2011-05-11T14:10:00.000+09:00

Apologies to the people who left comments recently. The notifications were sent to an old address and I just noticed the comments today. I've changed the notification reception address and I'll be better next time!

Introduction to regular expressions

2011-04-22T01:02:00.001+09:00

The technology that had the most impact on my workflow is definitely "regular expressions".

I discovered them at the end of the 90' when I was working on the conversion of a database output to a set of about 6000 static HTML pages. At the time, the editor of choice on the Mac was BBEdit from Barebones Software, but its free and "lite" version "BBEdit Lite" was also immensely popular. BBedit Lite has now been replaced by Textwrangler and just like its predecessor, Textwrangler can be used without paying a user license fee*.

What are regular expressions?

Regular expressions are a "search" function on steroïds. Regular expressions were created to find patterns in strings. They can find simple patterns like the word "pattern" in this text, or more complex patterns like "a string that starts with 'pa', followed by a letter that's repeated twice, followed by any three characters that are not 'space' or '@' or '^' and followed by a space".

This document uses its two first paragraphs (the paragraphs in italics, above) as a test ground. Paste that paragraph in your favorite regular expressions supporting text editor (I use Textwrangler for all the descriptions so you might want to use it too) then call the search window, check the "grep" box at its bottom and search for:

re[^ ]*

You should see colors appearing while you type the search terms.

What that expressions means is:
r followed by e followed by a group of characters that are not a space, or by nothing.

Hit Next and see what you get, then hit Cmd+G and see what you get. If you start from the top of the paragraph you should have 8 "matches".
Normal characters

Most characters represent themselves in regular expressions (regex), like a "normal" search.

→ r means r and e means e, " " means a space. In the same sequence. No magic here.
Special effects

Some characters have special effects:

→ [ starts a group of characters
→ ] ends that group
→ ^ means "not"
→ * means "zero or more of what just came"

So, our simple regular expression means:

"look for any string that has a r followed by a e followed by zero or more characters that are not a space."

Now, what if you need to find characters like ^, [, ] or *?
Cancelling special effects

When you want to find characters that have a special effect without "triggering" that special effect, you put a "\" in front of them:

→ \* means the character *
→ \[ means the character [

And since the character "\" has the special effect of removing the special effect of a character that has a special effect... then:

→ \\ means the character \

etc.

By the way, the character . has the special effect of matching "any one character" so if you're looking for a period, then you really want to look for the \. string...

Examples:

The regular expression ". " (. followed by space) will match any one character followed by a space. There are 78 strings that match this pattern in the paragraph.

The regular expression "\. " (\ followed by . followed by space) will match any period followed by a space. There are only 2 strings that match this pattern in the paragraph.

The regular expressions "re*." (re followed by * followed by .) will match any string that is composed of a r, followed by zero or more e, followed by any one character. There are 22 matches in the paragraph. Verify that you understand them all.

The regular expression ".e\*\." (. followed by e followed by \ followed by * followed by \ followed by .) will match the 4 characters string ee*. that you find at the end of the paragraph.
Triggering special effects

Some characters work the other way round: by themselves they do not have a special effect but if you stick the \ character before them, then their special effect is triggered.

→ t means t but \t means tabulation
→ r means r but \r means line break (specifically "carriage return")
→ s means s but \s means all sorts of white space, which includes spaces, tabulations, line breaks etc.

If the character does not have a special effect then using \ has no effect.

→ i means i and \i too means i

Such sequences (\ followed by a character) are usually called "escape sequences".
Remembering matches

If you want to "memorize" a match, for later use in the expression or in the "replace" field, then you put the corresponding expressions between parenthesis:

→ (re)[^ ]+ will produce the same matches as above, but will memorize the re part and not the rest.

→ re([^ ]+) will produce the same matches as above, but will not memorize the re part and instead will memorize the rest.

→ (re)([^ ]+) will produce the same matches as above and will memorize the 2 parts separately.
Using memorized matches

Now that the matches are remembered, you can use them. Use \1 to refer to the first memorized string, \2 to refer to the second memorized string etc...

→ (e)\1\*\. will produce the "ee*." string that you find at the end of the text.

→ search for (re)([^ ]+) and put \2\1 in the Replace: field:

(re) is the first group
([^ ]+) is the second group

\2\1 will thus put the second group before the first group.

The term "regular" matches the pattern: (re) matches re and ([^ ]+) matches gular. The replaced string will thus be "gularre".

→ search for (re)([^ ]+) and put \1\1_\[\2\] in the Replace: field:

(re) is the first group
([^ ]+) is the second group

\1\1_\[\2\] will put 2 instances of the first group, then an underbar, then [, then the second group, then ].

In the case of "regular", we'd have the following replacement string:
rere_[gular]
That's only the beginning...

What you need to check now is the special effects of some characters. If you've used Textwrangler it is all in the user manual, page 133, Chapter 8 (Searching with Grep), or you can call the Help with Cmd+? and you'll find a relevant link right away.

Textwrangler's regex is pretty standard so once you're used to it there, you can use it in other editors too. If what works in Textwrangler does not work there, check the idiosyncrasies of the editor you use.

Now, take a real world document and try to transform it by using a few regular expressions. A typical use case for a translator would be to convert a TMX file into a 2 column tab separated data set, or the opposite: to convert a 2 column tab separated data set into a TMX file. If you manage to do that you've created your first alignement based TMX converter!

* I try to use or discuss free software when possible because I think that is the way to go. People who want to use a free text editor on the Mac can use Aquamacs. It comes with all the goodness of emacs (including the same regular expressions) and looks and feels a lot like a "normal" Mac text editor.

When your external disks are not willing to go to bed...

2011-02-23T11:17:00.004+09:00

We've had problems with our iMacs bed time in the office pretty much since we started using them.

At night, they seem to refuse to fall asleep.

We've tried all the possible settings provided by the OSX interface. But nothing worked. Until I realized that the problems seemed to be related to the external back-up disks attached to them.

We use a LaCie and a Western Digital, both with a 1TB capacity, respectively connected to a first generation 24" Intel iMac and to a before-the-latest generation 27" iMac.

Sleep settings don't work for the hard disks
Manually unmounting the disks seems to solve the issue, but mounting them back is not trivial
OSX seems to unmount the disks when I log out from the Apple menu but when I log back in I have to restart all my applications

I have found a solution that requires the use of the "Fast user switch menu". The settings are as follows:

Go to System Preferences > Accounts
Check "Show fast user switch menu as" and choose the option you prefer
Make sure the "Show the Restart, Sleep, and Shut Down buttons" box is checked

Now, when you want to put the whole system to sleep, the solution is:

Click on the Fast user switch menu (top right of your screen)
Call the "Login Window..."
Press "Sleep"

Et voilà !

My guess is that the sleep option from the login window actually unmounts the hard disks and leaves them inactive until you enter your account again.

As a side note, those sleep problems also had a disturbing side effect: when I'd simply put the system to sleep the "old" way (either by calling "Sleep" from the Apple menu or by using the automation settings in "Energy Saver"), and tried to wake it up in the morning I'd have what looked like system freezes that sounded (yes, actually "sounded") related to the external hard disk activity. With the new system, I've had only one case of "freeze" in a few weeks of time, and it still kind of looks related to the external disk behavior.

In any case, this system seems to be allowing our Macs to spend their whole night sleeping and not struggling with hectic external disks... I'll need to check further what is the cause of the disks' inability to sleep, and also what is the cause of my freezes (not happening on the 24"), but that's for another post...

Java is not so dead after all...

2011-02-23T11:09:00.002+09:00

The announcement came from Oracle, a few weeks after Apple's declaration (see Java is dead! Long live Java?).

Basically all of Apple's Java efforts will be handled by Oracle, within the OpenJDK project and Oracle will release Java for Apple machines, not Apple anymore.

If you are interested in declarations, check this link: OpenJDK News, Nov. 12.

Before OpenJDK took charge of the OSX version of Java, there were a number of projects that attempted to use the FreeBSD version of OpenJDK to create something that would run under OSX.

Now, OSX has its own development project at OpenJDK and things are slowly progressing, which is a very good thing...

The project goals are:

Pass all appropriate certification tests for Java SE 7
Include a complete, native Cocoa-based UI Toolkit
Provide excellent performance

Which basically translates into: what Apple has been providing us with since the beginning of OSX, but by the people who are behind Java (and hopefully with simultaneous Windows/Linux/OSX releases).

If you want to build Java on OSX, you can. Follow the instructions on this page: Mac OS X Port. I have built Java 1.7 on my machine and it worked well with OmegaT. The only problem is that the UI toolkit still depends on X11, which means that your favorite Java application will not look like a native citizen of OSX. But that will happen!

If you want to see how the project advances and check the discussions (and participate in case you have a problem building the thing for example) check the following links:

The questions that remain unanswered are the following:

Will Java 1.7 on OSX be available at the time OSX 10.7 Lion is released next summer?
If not, will OSX 10.7 Lion include the current Apple released Java 1.6 by default an all new machines?
Once Java 1.7 is released by Oracle, will Apple include it in OSX bundles or will users have to go fetch it from Oracle's site ?

My take is that Java 1.7 will not be finished by the time Lion is released, and for the rest, I have no idea.
I'd like to say "yes" for a default Java 1.6 in Lion and "possible" for inclusion of Oracle's Java in further releases (after all OSX bundles plenty of third party development tools). We'll see.

But the future is definitely much brighter than it was back in October.

Java is dead! Long live Java?

2010-10-21T19:09:00.008+09:00

Apple just released a new update for Java 1.6 (both for OSX 10.6 and OSX 10.5, available from Software Update), pretty much the same day Steve Jobs introduce us to a few features of the upcoming version of OSX, 10.7 aka Lion.

The theme of the presentation was "Back to the Mac". Triple layered meaning...

Back to the Mac after spending so much time and energy on iOS and mobile devices
Software improvements to OSX directly coming from the iOS experience
Hardware improvements to the MacBook with the new incarnation of the MacBook Air, inheriting a lot of cool technology from the iPad.

The presentation is available directly from Apple's page. Skip the iLife stuff and directly go to minute 53' to see the OSX part. The App Store and Mission Control parts are really interesting.

Then, in my inbox, came the Java update. After a good news, a bad one (well, hopefully only half bad).

Quoting Apple: As of the release of Java for Mac OS X 10.6 Update 3, the version of Java that is ported by Apple, and that ships with Mac OS X, is deprecated.

The full release note is here: Java for Mac OS X 10.6 Update 3 and 10.5 Update 8 Release Notes

Shocking news.

For translators on the Mac, Java applications are the key to freedom from Windows, even though a lot of "switchers" use the Mac mostly to provide their Windows environment with a stable virtual foundation... On the top of my mind, here are the mainstream applications that depend on Java and are vital for translators who do not rely on Windows:

If you read between the lines of the release note though, you can see that what is deprecated is no Java on the Mac in general, but "the version of Java that is ported by Apple, and that ships with Mac OS X".

With the recent acquisition of Sun by Oracle (Oracle makes massive use of Java), the opening of the JDK source by Sun a few years ago and the currently existing efforts to port that OpenJDK to the Mac, one can also see that move as a way for Apple to say that Mac users will not be left without Java on the Mac, because either Oracle or the OpenJDK community will eventually deliver something that Java users on Mac can still use to run their favorite applications.

In any case, it will eventually be possible to install a foreign (compatible) JRE on Mac that runs all our applications. I've tried a few days ago with Soylatte but I was not able to fully run OmegaT in it, and the windowing system was X11 (with all its UI glitches).

Still, as was mentioned today on the Java-dev list hosted by Apple, it is very unlikely that Apple will just remove Java from OSX. Java is big in education and multiplatform development and Apple has 20% of the PC share in the US as of today (cf the very first part of today's presentation). So Apple is probably thinking of something else.

In any case, right now I don't think Mac users of Java apps have anything to fear. They can keep their Snow Leopard Mac with the latest supported Java and don't have to upgrade to anything. We have about 8 months before Lion's release, hopefully Java we'll be there too in one form or another.

And apologies for the 10 months long blank on this blog...

(updated on 10/22)

New update (10/22): Steve Jobs hints at a different approach, via Hacker News: "Sun (now Oracle) supplies Java for all other platforms. They have their own release schedules, which are almost always different than ours, so the Java we ship is always a version behind. This may not be the best way to do it"

OSX + Windows hybrid systems

2010-01-02T01:41:00.000+09:00

Apple has made it very easy for Windows people to "switch" to the Mac with its adoption of Intel CPUs a few years ago.

What people do when they switch though is not only buy a Mac because it's also a PC, they dump their Windows habits altogether and start computing on the Mac side only.

That's good for most of what computing is about nowadays: write a document, browse the web, exchange mails, listen to music, manage pictures and edit a little bit of video.

Now, for professionals, leaving Windows altogether is a totally different issue. The first problem is of course the fact that some of the applications they use may not have equivalents on the Mac side. We are all aware that neither Trados nor MemoQ come with a Mac version...

The other problem is that even if you're willing to dump your Windows software, you may have to pay new licensing fees for something equivalent on the Mac side... The new software may be better integrated to the Mac ecology, but since you're still used to your Windows ways, it may take some time before you manage to be as productive with your new environment...

On the positive side, using Windows inside Mac with a virtualization software is doubleplusgood because:
1) Windows is less likely to infect your whole system since it runs in a closed box
2) It is also less likely to be an annoyance because when there is a problem, it is always possible to go back to a previous "snapshot" of its state.

There, you have tamed the Windows beast by putting it in a Mac box...

But working in such a hybrid environment comes with its set of problems: keyboard shortcuts that are not similar in Windows and Mac, technology that works better in "straight" environments (printing, back up etc)...

This is not to say that most of the existing virtualization packages have not solved most of those issues, but rather that you are bound to find glitches sometimes. Et voilà ! If you belong to the hybrid category of professionals who want to get a Mac but can't leave Windows right away then Karin Adamczyk's list is for you !

http://tech.groups.yahoo.com/group/MacSwitch/

The list is a place where a number of "people who have there before" will explain to you all the subtleties of using your Windows environment on your Mac. Karin's experience has proved very useful on other lists and I'm sure you'll find the place comfortable.

OmegaT and Snow Leopard(anti-aliasing problem - solved)

2009-09-09T11:51:00.003+09:00

I was surprised to see a bad lack of anti-aliasing (font smoothing) when I ran OmegaT 2.0 for the first time in Snow Leopard.

Work from English was possible, but from Japanese... Forget it !

The problem occurred in the Editor pane of OmegaT, not in the Matches or Glossary panes, and I suspected recent developments in the Editor to be the cause of the problem since OmegaT 1.8 did not show this issue.

After searching for information, a Java engineer at Apple who happens to monitor the Mac Java-dev list told me that the new Java 6 anti-aliasing default on OSX was probably the cause of the problem. He suggested to either add a line in the code, or to change the default value directly from the command line.

A brief exchange with the OmegaT developers concluded that the command line was the best approach especially since command line parameters could be hard coded in the Mac bundle.

The next release of OmegaT 2.0 will happen in a few days and the Mac package will include the font-smoothing parameter.

In the meanwhile, Mac users who work with the standard OmegaT package (the one that comes with the file OmegaT.jar) can start OmegaT from the command line with the following parameter:

$ java -Dapple.awt.graphics.UseQuartz="true" -jar OmegaT.jar

Users of the Mac package (the OmegaT.app file) can modify it so that it is launched with the correct parameters:

right-click on OmegaT.app and select Show Package Contents
find the info.plist file within the Contents folder and open it with your favorite text editor

replace the following code:


<key>Properties</key>
<dict>
 <key>apple.laf.useScreenMenuBar</key>
 <string>true</string>
</dict>

with:


<key>Properties</key>
<dict>
 <key>apple.laf.useScreenMenuBar</key>
 <string>true</string>
 <key>apple.awt.graphics.UseQuartz</key>
 <string>true</string>
</dict>

save the file, close the Contents folder, and relaunch OmegaT.app

The two solutions are equivalent and should transmit the correct property to the system when you use OmegaT.
(Special thanks to Mike Swingler at Apple.)

Okapi new version

2009-08-30T18:41:00.001+09:00

In case that had escaped you:

<quote>

Hello everyone,

We are happy to announce the milestone 3 of the Okapi Framework for Java.

To try to make things easier there are now two main distributions:

=== okapi-lib (for developers):

--> This distribution includes the libraries, documentation and examples you would need to use the Okapi Framework with your programs. It also include Tikal, a command-line tool to do basic task like simple extract and merge. This distribution is not UI dependent and therefore the same for all platforms.

=== okapi-apps (for users and developers): <-- The one you are likely to want

--> This distribution is the same as okapi-lib (minus the developers documentation). And in addition, it includes the UI-dependent components of the framework, as well as Rainbow (Localization Toolbox) and Ratel (SRX Editor). Because the UI depends on each platform, there are different flavors of this distribution: Windows, Linux (32-bit and 64-bit), and Macintosh (Carbon and now Cocoa).

All this can be downloaded from Okapi's main Web site:
http://okapi.opentag.com/downloads.html,

as well as from the Google-Code project's site:
http://code.google.com/p/okapi/downloads/list.

A large part of the work done for this milestone is not visible: We moved the build structure to Maven, so we can develop using continuous integration more efficiently. Ultimately it should make the framework more robust and better tested.

We did managed to work on a few visible changes too :) Here are some of them:

=== The first version of Tikal in Java has been implemented. This tool allows you to perform simple tasks from the command-line. For example:

C:/Tmp>tikal -x *.docx *.html -sl EN -tl FR

will extract to XLIFF all the DOCX and HTML files in the Tmp directory.

C:/Tmp>tikal -m *.xlf -sl EN -tl FR

will merge them back into their respective formats.

For more information on Tikal, see http://okapi.opentag.com/help/applications/tikal/index.html.

=== Various bugs have been fixed in several filters (thanks for the bugs reports) and some improvements have been implemented in others.

=== There is a new filter for Qt TS files.

=== Cocoa support has been added for the Macintosh.

=== There is a new TM connector to query Translate Toolkit TM servers. You can try it using Tikal. For example, if you have a local server running on port 8080, the command:

C:/>tikal -q "open file" -tt localhost:8080 -sl EN -tl FR

will get the matches for "open file" in that TM.

=== As usual, a more complete list of the main changes can be seen in the changes.html document that comes with the distribution.

Bug reports and enhancement or features requests can be posted here:
http://code.google.com/p/okapi/issues/list

Cheers,
-the Okapi Team

<end quote>

Snow Leopard

2009-08-29T14:21:00.000+09:00

I've only used it for a few hours but here are the first things I found:

1) Default Java version is Java 1.6, and OmegaT seems to have issues with that. It works but there is an issue with the font selection that is not respected in the Editor window.

2) The input method can be set to stick to a document. For ex, you can have a TextEdit document that uses Kotoeri, another that uses US and changing of document will not change the input method. That's an improvement over the situation in Tiger where, if I remember well, the input method was "attached" to the application but not to the document.

3) The old option "multilingual spellchecking" can use a subset of the available languages. That way, you can more efficiently check the spelling without changing the language in the spellchecker interface every time a paragraph uses a different language.

4) The spellchecker can also automatically correct your mistakes.

5) The services are indeed much better integrated to the workflow. A right click on an element (text, image etc) will trigger a contextual menu that shows possible services for that element.

Calculator bug ?

2009-08-28T11:39:00.003+09:00

This bug seems to have been fixed in Snow Leopard.

My bug report to Apple:

Summary:
Calculator does not accept "." input after conversion from the "Convert" menu.

Steps to reproduce:
1- enter a value with a decimal point, the decimal point can be entered either from the keyboard or from the the Calculator UI.
2- select any conversion from the Convert menu
3- the conversion result is displayed
4- enter a value with a decimal point again

Expected result:
The new value should have a decimal point in the location where it has been input

Actual result:
The decimal point cannot be input, neither from the keyboard nor from the Calculator UI. It is necessary to hit "C" on the Calculator UI to reinitialize Calculator to be able again to input a decimal point.

OmegaT Java Web Start

2009-08-05T10:08:00.005+09:00

In previous article, I mentioned the release of OmegaT as a Java Web Start application.

Once OmegaT.jnlp is downloaded, a double-click should open it in Java Web Start.app.

If that is not the case, if it opens as a text file for example, it means that .jnlp files associations to Java Web Start.app are broken.

To fix that, right-click on the .jnlp file, Choose "Open With", select "Others..." at the bottom of the list and browse your disk to find the application.

Java Web Start.app is located in /Applications/Utilities/Java/ for older versions of Java and in /System/Library/CoreServices/ for the most recent version of Java (Java update 4, released on June 15 2009).

Once you have selected the application, check the "Always open with" box at the bottom of the dialog.

Thanks to Yves who send me the comment that triggered this "investigation" and to this blog article that clarified everything.

Rainbow, XLIFF and OmegaT

2009-08-04T22:23:00.013+09:00

(I've updated the contents of the file to make things clearer for people who are not familiar with XLIFF - 08/05)

OmegaT's support for complex XLIFF is not really optimal. I'm going to spare you the details but basically, unless you tweak the file significantly, OmegaT is likely not going to be able to leverage all the available data.

Let's say that we have a XLIFF file with the following data:

First segment, not yet translated:
ba bi bu
In OmegaT, this part should be in a supported source file located in /source/

Reference translation from a first reference file:
ba bi, translated to バ　ビ, matches the segment to translate at 66%
In OmegaT, this part should be in a TMX file located in /tm/

Reference translation from a second reference file:
ba bi bu be, translated to バ　ビ　ブ　ベ, matches the segment to translate at 75%
This part too should be in a TMX file located in /tm/

Second segment, already translated in the same document:
ba bi, translated to バ　ビ
Since this data comes from the same document and is a validated translation, it should be in the project_save.tmx file located in /omegat/

Such an XLIFF file would look like this:

First segment, not yet translated(<target> is empty):

<trans-unit approved="no" id="source_file">
  <source xml:lang="en">ba bi bu</source>
  <target state="new" xml:lang="ja"/>

First reference translation for that segment:

 <alt-trans match-quality="66" origin="first_reference_translation">
    <source xml:lang="en">ba bi</source>
    <target xml:lang="ja">バ　 ビ</target>
  </alt-trans>

Second reference translation for that segment:

  <alt-trans match-quality="75" origin="second_reference_translation">
    <source xml:lang="en">ba bi bu be</source>
    <target xml:lang="ja">バ　ビ　ブ　ベ</target>
  </alt-trans>
</trans-unit>

(↑ end of the first segment)

Second segment, already translated in that document:

<trans-unit approved="yes" id="source_file">
  <source xml:lang="en">ba bi</source>
  <target xml:lang="ja">バ　 ビ</target>
</trans-unit>

If you want to know more about the XLIFF specification, look at this page: XLIFF Version 1.2

Now, let's see how Rainbow can help us leveraging all the data directly from within OmegaT.

Rainbow

Here comes Rainbow. I'm mentioned Rainbow, or the Okapi Framework a number of times already.

Rainbow is a Java software that acts as a swiss army knife for localization processes. It is a filter to/from complex formats, it is a batch search/replace tool etc.

Don't forget to see the Okapi Webinar that was given a few weeks ago by Yves Savourel. It is about 1h long and goes into great details to show you what Rainbow/Okapi is about. OmegaT is used as an example too and the following text can be considered as a detailed explanation of what you see in the Webinar.

Webinar: http://www.translate.com/Language_Tech_Center/Webinar_Portal.aspx?id=132

The Okapi group has decided to frequently release snapshots of the code so that users don't have to wait for milestones to get a taste of the most recent features.
The snapshots are available here: http://okapi.opentag.com/snapshots/. Get the rainbow_carbon-macosx_... file.

When you unzip the package, you will find a rainbow.sh script file. Open the Terminal where the file is located, make the file executable by typing the following command at the prompt:
chmod +x rainbow.sh

Then, call the script from Terminal to launch Rainbow.

When you launch Rainbow, you're displayed with an empty file list.

drag & drop your XLIFF file on that list. It should be the list corresponding to the "Input List 1" tab.
click on the "languages and encoding" tab and set the appropriate information. For example, an English manual translated to Japanese should be:
- Source=EN (you can use a variant, like EN-US)
- Encoding=UTF-8
- Target=JA
- Encoding=UTF-8
Then go to the "Utilities > Translation Package Creation"
Select OmegaT
click on the Package Location tab
Select a directory where Rainbow will create the OmegaT project
Click OK.

You're back to the main window where the status bar indicates that the XLIFF file has been processed. What has Rainbow done to your XLIFF file ?

XLIFF

A XLIFF file is a mix of a number of things. First, it contains strings to translate in <trans-unit> sections:

<trans-unit approved="no" id="source_file">
  <source xml:lang="en">ba bi bu</source>
  <target state="new" xml:lang="ja"/>
</trans-unit>

Then, it may contain reference data. The first type is, obviously, what has already been translated, in similar <trans-unit> sections:

<trans-unit approved="yes" id="source_file">
  <source xml:lang="en">ba bi</source>
  <target xml:lang="ja">バ　 ビ</target>
</trans-unit>

The other type is what is embedded to serve as reference, it comes as <alt-trans> sections within a <trans-unit>:

<trans-unit approved="no" id="source_file">
  <source xml:lang="en">ba bi bu</source>
  <target state="new" xml:lang="ja"/>
 <alt-trans match-quality="66" origin="first_reference_translation">
    <source xml:lang="en">ba bi</source>
    <target xml:lang="ja">バ　 ビ</target>
  </alt-trans>
  <alt-trans match-quality="75" origin="second_reference_translation">
    <source xml:lang="en">ba bi bu be</source>
    <target xml:lang="ja">バ　ビ　ブ　ベ</target>
  </alt-trans>
</trans-unit>

When Rainbow is used to create OmegaT projects from XLIFF files it looks for the 3 types of information and separates them in a way that OmegaT can manage.

OmegaT cannot manage "empty" <target> elements in <trans-unit> sections. So, Rainbow recreates the source file so that it contains the <source> data in the <target> section. That way, OmegaT only has to overwrite that data:
```
<trans-unit id="source_file">
  <source xml:lang="en">ba bi bu</source>
  <target xml:lang="ja">ba bi bu</target>
</trans-unit>
```
OmegaT cannot manage already translated data in the XLIFF file. So, Rainbow creates a typical "already translated" OmegaT data file that contains the already translated segments: the project_save.tmx located in the /omegat/ folder of the project:
```
<tu tuid="source_file">
  <tuv xml:lang="en"><seg>ba bi</seg></tuv>
  <tuv xml:lang="ja"><seg>バ　ビ</seg></tuv>
</tu>
```

OmegaT cannot managet reference data in the XLIFF file. So, Rainbow creates a typical "reference translation" OmegaT data file that contains all the embedded translation segments: the alternate.tmx located in the /tm/ folder of the project:

<tu tuid="first_reference_translation">
 <tuv xml:lang="en"><seg>ba bi</seg></tuv>
 <tuv xml:lang="ja"><seg>バ　ビ</seg></tuv>
</tu>

<tu tuid="second_reference_translation">
 <tuv xml:lang="en"><seg>ba bi bu be</seg></tuv>
 <tuv xml:lang="ja"><seg>バ　ビ　ブ　ベ</seg></tuv>
</tu>

That way, OmegaT can seamlessly access all the data available in that complex XLIFF file. Since Rainbow creates a whole OmegaT project, the only thing necessary to proceed is to open the project with OmegaT and translate.

Delivery

Nothing could be simpler. When you are done with your translation, create the translated files from within OmegaT.

Then, drag and drop the manifest.xml file located at the root of the OmegaT project created by Rainbow on Rainbow's main window where the Input List 1 tab is displayed. When manifest.xml is visible on the list, use the "Utilities > Translation Package Post-Processing..." menu.

Rainbow will use all the data it saved in the project to recreate a "proper" XLIFF file for delivery. That file contains all the data that was contained by the original XLIFF, its structure is identical. The only difference is that now it includes the data you have translated in OmegaT.

Excel files with colored non translatables... (2)

2009-07-29T16:06:00.007+09:00

Just to show you that I am not lying:

Here is one of the Excel cells that I have to translate:

<h1>This is ugly<br />ugly ugly ugly</h1>Ugly ugly ugly ugly ugly ugly:<br /><br /><a href='%%LINK_A%%' class='yellow'>Ugly ugly:</a> Ugly ugly ugly ugly.<br /><a href='%%LINK_B%%' class='yellow'>Ugly ugly:</a> Ugly ugly ugly ugly ugly.<br /><a href='%%LINK_C%%' class='yellow'>Ugly ugly:</a> Ugly ugly ugly ugly ugly. <br /><a href='%%LINK_D%%' class='yellow'>Ugly ugly:</a> Ugly ugly ugly ugly ugly.!

Putting that straight into OmegaT as an ODS file

keeps the various styles that exist in the original Excel file (fonts/colors/etc)
keeps the HTML codes as plain text.

So, in OmegaT, you end up with segments like this (I colored in green the formating inherited from the Excel file, and in red the original HTML tags):

First segment:

<h1><f0>This is ugly</f0><f1><br /></f1><f2>ugly ugly ugly</f2><f3></h1></f3><f4>Ugly ugly ugly ugly ugly </f4><f5>ugly</f5><f6>:</f6><f7><br /><br /><a href='%%LINK_A%%' class='yellow'></f7><f8>Ugly </f8><f9>ugly:</f9><f10></a></f10><f11> </f11><f12><s13/>Ugly ugly ugly ugly</f12><f14>.</f14><f15><br /><a href='%%LINK_B%%' </f15><f16>class='yellow'></f16><f17>Ugly ugly:</f17><f18></a> </f18><f19><s20/>Ugly ugly ugly ugly ugly</f19><f21>.</f21><f22><br /><a </f22><f23>href='%%LINK_C%%' class='yellow'></f23><f24>Ugly ugly:</f24><f25></a> </f25><f26>Ugly </f26><f27><s28/>ugly ugly </f27><f29>ugly ugly</f29><f30>.

Second segment:

</f30><f31><br /><a href='%%LINK_D%%' class='yellow'></f31><f32>Ugly </f32><f33>ugly</f33><f34>:</f34><f35></a> </f35><f36>U</f36><f37>gly ugly ugly ugly ugly</f37><f38>.</f38>

You see ?

All the original HTML is here, and all the original formatting is applied to each cell part separately...

This is obviously not the solution. For one thing, the inherited formatting (all the green tags) is totally irrelevant as far as the translation is concerned. Then, the HTML tags should rather be handled as HTML and not as plain text, to be able to see the translatable text better, but also to reduce the modification risks when you translate the segment.

Now, if you follow my earlier advice, the above segment would look like this in OmegaT (with blue color for emphasis), after being handled as a "normal" HTML file:

First segment:

This is ugly<br0/>ugly ugly ugly

(notice that the tags <h1> and </h1> are not shown since they are block level tags and the whole block is the segment! You just reduced the total number of tags in the segment!)

Second segment:

Ugly ugly ugly ugly ugly ugly:<br0/><br1/><a2>Ugly ugly:</a2> Ugly ugly ugly ugly.<br3/><a4>Ugly ugly:</a4> Ugly ugly ugly ugly ugly.<br5/><a6>Ugly ugly:</a6> Ugly ugly ugly ugly ugly.

Third segment:

<br7/><a8>Ugly ugly:</a8> Ugly ugly ugly ugly ugly.!

Much better isn't it ? Now, how much time and energy do you think this trick will save you next time you have such a (not so uncommon) file to translate ?

ps: I did try to do all the heavy editing in Emacs, but I fear I am not yet familiar enough with its regex syntax. I eventually had to revert to TextWrangler, but I am not giving up...

ps2: If you know a CAT tool that does not require any manipulation to reach a manageable tag number, let me know !

OmegaT small (?) update

2009-07-29T15:42:00.000+09:00

OmegaT 2.0.3 update 2 has been released.

From the release file:

================================================
OmegaT beta version 2.0.3 update 2 has been released. For the first time, OmegaT is available as a Java Web Start application (http://en.wikipedia.org/wiki/Java_Web_Start).

Launching OmegaT from http://omegat.sourceforge.net/webstart.html requires no installation, and future updates of this version will happen automatically.

Two bugs have been corrected. One concerns segment detection in the Editor, and the other StarDict dictionaries.

Belarusian, Dutch and Catalan localisations have been updated.The OmegaT Project always welcomes developers, localizers and users to contribute their experience, knowledge and insights to the software we release.
================================================

Regarding Webstart and privacy (quoting Tony):

OmegaT Java Webstart does NOT save any of your information to our web servers. The application runs on YOUR machine. Your documents and translation memories remain on your computer, and the OmegaT project will have no access to your work or information.

(end quote)

The fact that OmegaT is now available directly from the network without any specific install procedure does not mean that OmegaT better supports network interaction between translators (data sharing etc). It only means that it is easier to distribute/use/update.

There are still issues to iron out though: how to use the Lucene tokenizer with that WebStart version... We're investigating this right now... :)

Excel files with colored non translatables...

2009-07-29T15:18:00.003+09:00

Here comes an excel file, with pseudo HTML in the cells.

The HTML tags are red and must not be modified. If you want how the segments look check the follow up post.

Translating that in OmegaT is relatively straightforward:

save the file as ODS in Openffice.org (or NeoOffice)
put that source file in the /source/ folder of your OmegaT project
load the project and translate

The problem is that not only you are going to have all the HTML tags displayed for what they are within the translatable text, but you're going to have to deal with the red color tags that will surround all the HTML...

Not user friendly at all...

Another solution is to do like this:

copy-paste the column into a text file -> no more red color, will deal with that later
insert a visible marker like @@@ at each end of line
save the file as .html -> no more full HTML tags in the segments
put in /source/
go to Options > Segmentation and add 2 rules. One where you segment before @@@ and one where you segment after @@@, that way you'll nicely isolate the marker and it will be translated only once
load, translate

The resulting file should contain all the original tags, without modifications, but some characters in the original may have been converted to HTML references. Replace those with the original character if you think it is better.

Now, open your file in a text editor, remove the @@@ markers and paste the contents into a Write page in OpenOffice.

There, do a "Regular Expression" search for the string: (<[^>]*>)

The string means: a "<" followed by a number of anything but ">" followed by a ">": (basically any HTML tag). The surrounding parenthesis put the matching string into a memory for later retrieval!

and replace by "&" with the style "font color=red". "&" means "the group that was just put into memory".

All your HTML tags should be colored in red now.

Copy-paste the contents into the original file where it needs to be, and deliver !!! Also make sure that one line corresponds to one cell (manipulating the @@@ marker should not change the overall structure but one never knows!)

(There are probably easier ways to deal with such files. Let me know!)

Yes ! Okapi snapshots available !

2009-07-21T22:50:00.001+09:00

From Yves Savourel @ Okapi Framework:

If you are interested in testing the latest build of the Java-based Okapi tools and libraries you can download them from here:
http://okapi.opentag.com/snapshots/

Those are the latest development builds (more recent than the normal releases), they have all the latest features, BUT they are not tested and may be unstable. They are the versions the developers are using. Use them at you own risks.

The times listed in the directory is date/time when the files was generated (in US Pacific Time). We will update those snapshots relatively frequently.

OmegaT small update

2009-07-09T15:09:00.000+09:00

OmegaT 2.0.3_1 was just released, it comes now with a complete Japanese/German/Slovenian UI/tutorial.

https://sourceforge.net/projects/omegat/files/

Okapi webinar

2009-07-07T10:39:00.001+09:00

A message from Okapi's Yves Savourel:

Just a note to let you know that I'll be giving a little introduction on using the Okapi Tools. Note that it will be focused on the new Java-based tools.

ENLASO is hosting this free webinar on July 16th at noon Mountain Time.
It's free and you can register here:
https://enlasoevents.webex.com/enlasoevents/onstage/g.php?t=a&d=662713198

The latest version of the Java Okapi tools is here:
http://okapi.opentag.com/

Bored Trados users ?

2009-07-02T19:03:00.002+09:00

For bored Trados users who want to work in a free software environment, here are the latest news:

1) OmegaT is able to translate TTX files that have source=target (output option if I am not mistaken), that requires a small utility called Toxic, to be found here:
http://www.omegat.org/resources/toxic.zip

2) It is possible to deliver "cleaned/uncleaned" file sets by translating the file in OmegaT and processing the resulting TMX in OpenOffice.org with the Anaphraseus macro (a Wordfast equivalent for OOo). The discussion about the process is here:
http://tech.groups.yahoo.com/group/OmegaT/message/14705

And Anaphraseus is here:
http://sourceforge.net/projects/anaphraseus/

(updated 7/8)

3) Ask your Trados clients to send you TMX memories instead of Trados memories, you'll be able to use them in OmegaT without problems. Trados seems to have problems creating conforming TMX files. If OmegaT complains, use TMXValidator from Maxprograms.

TMXValidator is here: http://www.maxprograms.com/products/tmxvalidator.html

4) Some file formats are not directly supported by OmegaT. Use Rainbow to create OmegaT projects from unsupported files. Not all files supported by Trados are supported by Rainbow but Rainbow still covers a very reasonable range of "exotic" formats.

OmegaT directly supports the following formats:

OpenDocument/OpenOffice.org
Microsoft Open XML
DocBook XML
HTML, XHTML
TeX
Plain text
SRT subtitles
PO (monolingual)
XLIFF (Okapi generated)
ResX ressources
INI ('key=value' format)
Java bundle.properties
HTML Help Compiler
QuarkXPress CopyFlow Gold

Rainbow has filter for the following formats: Okapi Framework - Filters. Rainbow is here: http://okapi.opentag.com/downloads.html