MAJOR NEW FEATURES

• Lion autosave and version support
• Ignoring certain placeholder string
• Automatic Xcode Project Import

NEW FEATURES

• Added support for the ibtool shipped in Xcode 4.3
• Strings and TXT files now retain the encoding of the original
• Improved language reimport to not touch disabled keys and leave translations that are equal to the reference
• Xcode export replaces the project file only when actually making changes

CHANGES

• Inactive keys are no longer included in key count
• Added menu command to delete a translation
• File content now allows multiple selection
• The “Mark as” buttons now act on the selection of the visible items

FIXES

• The Localization Manager help now works as it should
• Backups of files with a “.” name prefix are now stored correctly
• Interface preview works again on Lion
• Localization Dictionary con import Manager files again

I know it’s been quite silent the last months. Lately, I’ve been doing a lot of stuff like moving flats, starting a book, writing a diploma thesis, becoming father and so on that kept me very very busy. And that was the reason the Localization Suite had to step back for a few moments. However no longer!

I’m proud to announce the first “final” release in years. No beta, no release candidate. Just a plain release. As I announced previously, I switched the version numbers to something that made more sense for the kind of continuous development cycle I have. From now on, versions will be named by their release date: .. So the version to be released today will be called “11.4″.

I actually have the feeling that a version 11 does indeed suite the amount of features I added throughout the last few years. For this release, there are a couple of very big ones:

• Automatic Xcode Integration
• A completely re-done preference architecture
• Consistency checks in the database
• Better multi-user support
• Compressed file formats
• String file mimicking the original
• Editing english strings
• And tons of bug fixes

You can find the full release notes of the Localization Manager 11.4 here. So no time be wasted — get the newest version though Sparkle or manually now!

I am eagerly waiting for feedback!
Max

Hence, I am thinking about switching to a Ubuntu-like versioning system: “YEAR.MONTH”. The current would then be “10.12″. This better suits the actual development process — continuous development with new features an bug fixes not coming in chunks but steadily in smaller portions.

What do you think?
I want to drop that damn “b” or nowadays “rc”

However, I want to share something with you that has been lying around here for quite some time now. As a reader of the blog you should know that I am working on an automatic layouting approach for Max OS (and maybe later iPhone) interfaces.

Here is how it works!

I know this is lengthy and there’s some blah-blah surrounding the actual work — it’s been kind of my bachelor thesis, so that had to be. Also it’s not the description of the state-of-the-art since I did a couple of improvements since. The core, however, is still the same.

I am looking forward to getting feedback. Let me know what you think!
Max

Right now I’m sitting in my plane to WWDC waiting for taxi. If any one would like to meet – just drop me a line to max@loc-suite.org.

Max

PS: If you were quick and already grabbed the update yesterday, please check again. I just fixed a crash most of you might experience.

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…

Bundle-based documents: The previous file format of the databases (the files you edit in the Manager, suffix .ldb) was a keyed archived file. The problems are obvious: as it’s binary, no diffs can be made for version control system, all contents have to be uploaded on every commit and one cannot have a look inside. Additionally, if you wanted to store extra files (like backups of the reference language files needed for incremental localization), they would have to be encoded and stored inside this archived object tree, unnecessarily increasing file size.
This is different now: storing the projects as bundles allows the file to separate the actual contents (like objects, indexes, data) from the auxiliary information like backups or attachments (see later). This format is somewhat like the already present Localizer bundle format, where these things were already kept separate.

File versions: One major drawback of the old format was that only one version of backed-up files could be stored. This is very problematic for incremental localization, where you need the exact old reference file for each language variant. When now two localized files are based on different versions of the reference file, we have to store the backups for both versions. This is now possible in the current file format, resulting in much better results of “Synchronize”.

Attachments: Now that the file format allows auxiliary files to be stored separately, it is also possible to have additional information persisted. A long-requested feature was the ability to attach additional media files to key object. These could be for example images of strings being used in context. Imagine having a progress sheet where the status text is loaded dynamically. Currently, the context was only able to be conveyed using comments describing where and how it’s used. However, in some applications not only the context, but also the sizing is important — take the iPhone. You’re now able to attach a screen shot to the key objects for the displayed strings, allowing the translator to get a better view on how it will be used and how much space he or she has.

All these features are available in the current nightly build. So much for today, read you soon.

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.