I have invested lots of time into this particular feature, which I think is the major (technical) problem of Mac localization. From the preview I showed in in this post, there were like a zillion of problems to be solved. Things became more complex that I imagined. However, finally it seems to work pretty well on some examples.

Here is one of these working examples:

This is a preview of an interface in one of my test tools. Basically this is what you’ll also see in the Manager or Localizer. So now, let’s put in some German dummy-text:

The interface has now been adjusted to fit all texts as good as possible. The former Cancel button had to extend in width and hence the Yes button had to do so, too. The approach will work with more complex windows as well, but this simple example shows the effects already quite well.

One of the things I’ve (thought of for weeks but) implemented just today is the red box you see there. I defined an arbitrary fixed width for the window. Without this definition, it would have extended in width.

I will eventually publish my work (maybe also here) and disclose the full details of how this process works. For now there’s only the user’s view. If you like, you can download a nightly build of a layout-enabled Localization Manager. As always – just go here and grab the “Localization Manager Layout”.

Next up will be to make the process ready for the big stage. There are some essential things still missing or buggy. If this is done, I will merge the layout into the main branch, publishing it to all developers.

I am pretty excited, and would love to hear some feedback.
Have fun, Max

PS: Is someone of you going to WWDC this year? I’ll be there. Maybe we can meet…

• First, of course, you can open and load dictionaries and files like it’s in Localizer. This is needed for the following features.
• Trivially, this enables support for automatic translation. While the best place to do this is still the Localizer, you are now able to automatically translate files in the Manager as well. This may come in quite handy when you split up a interface file and want to transfer the strings from one to the other.
• Next up are embedded dictionaries. Having loaded dictionaries in the manager enables the ability to include tailored — embedded — dictionaries in exported Localizer files. This reduces the need to ship dictionaries separately and comes in handy especially when the developer wants to ensure consistency. So embedding the system glossaries and the one of your old version will ensure maximum consistency. Additionally, these embedded dictionary will contain keys that match only. This has two benefits: first the dictionary will be smaller and thus the file, and second, you do not transfer your complete knowledge base. The translator could “steal” (i.e. copy it and keep it as his own) the dictionary, so you will want to keep it as small as possible.
• One thing else that can be done when having dictionaries, is calculating statistics. I am very proud to present the (like version 2.0) updated statistics panel:
  
  Not only that the sections are collapsible and nicely animated (yay), the major new thing is the third part. As you can see, there are detailed statistics about the selected keys in relation to your knowledge base. This is especially interesting for professional translators to estimate their work and calculate the price for a translation. Counts are being given in key pairs and words.

That’s the main thing. I also fixed several bugs (see commit log for details) and added export and import facilities to the Localizer. This enables Localizers to save their work done to a dictionary in order to not loose any data. And this allows agencies to work on Localizer files, but to export the actual translation work to XLIFF and reimport it later. Flexibility as it ought to be (at least in my opinion)!

I’d love to get some feedback.
BTW: These things are online right now. Have a look in the nightly trunk.

Currently there are two usages: First, the matching. While this piece of functionality used to have it’s own (admittedly quite limited) segmentation, it is now using the new one from the framework. This changed nothing when looking at the features, except that the code is now well-tested and more reliable.

The second usage is in Localizer. Splitting longer strings into shorter ones eases the localization process and also increases the probability of finding matching strings. Thus, Localizer now features a filter setting for segmentation by either sentences and paragraphs.

Segmentation in Localizer will be available in tomorrow’s nightly build.