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…

However, this has changed. Some users came up to me and requested the ability to edit the english (reference) strings from the outside. They have their localizations sent to a professional agency and they tend to find typos in the english strings. Instead of them having to go into each file and look for the occurrence, they wanted to be able to import a mono-lingual strings file that came from the agency and automatically have their typos fixed.

Only very few may know, that solving this issue is quite an issue. The problem was that the Loc-Suite had only one dirty state for the reference language. But now we’d need two: when the contents in the file were modified, imported and need to be written to all other languages and when the reference language was changed in the database. As you might imagine, from a developers experience, splitting such a fundamental and central state is a very sensitive change. Luckily it was not overly much code to change, but still it was a lot of code to check that it worked right. Luckily I got unit tests

The short message is: it’s in there. From the next nightly build on, you will be able to edit the reference language right from the Localization Manager. This function is not yet in the Localizer. Makes few sense there, I think — send me a message if you feel you need this.

When you now have a look at the change status of your files in the manager, you might get a a little cumbersome picture:

This means that the reference language was changed in two ways: the file was modified and the changes have been imported (thus the “Reference”) and the developer edited some of the strings in the Manager (thus the “English”). What will happen now? As the reference changed, first all other languages will be written. After that is finished, the reference file will be updated and immediately rescanned again. The rescan is more or less a security and convenience concern.

That’s it for today. Have a nice weekend!
Max

• 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.