07/12: Hi there, Mountain Lion

July 12, 2012

I just published Version 12.7 through Sparkle. Not so much new stuff, however quite a ton of fixes with large projects, concurrency and especially Mountain Lion. Go check it out and let me know what you think!

Max

03/23: Localization Suite 12.3

March 23, 2012

It’s been a very very long time since the last update. This makes me even happier to announce that I finally managed to get the latest changes out via Sparkle. Here are the release notes:

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

04/05: We have a release…

April 5, 2011

Hey fellows,

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

12/03: Loc-Suite 2011 Deluxe m0nster mega SPECIAL edition Xtreme+

December 3, 2010

Okay, that title is a bit too exaggerated. But I am thinking about switching the version model. The Suite has been 3.0 Beta since like forever. Many things have changed but I’d never call it “finished”.

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” ;)

07/08: How automatic layout works

July 8, 2010

Unfortunately I have been very busy the last weeks in doing other things than the Loc-Suite. This is kind of the problem with side-projects.

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

06/04: Labeling it RC

June 4, 2010

Just a quick heads up: I labeled the latest nightly build to be a release candidate. 3.0rc. Finally. This is the official end of beta phases – at least for version 3.0.

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.

05/27: The most gorgeous Icons. Ever.

May 27, 2010

Well, I don’t want to say too much. An icon is worth a thousand words. But put simply, these are amongst the most gorgeous application icons I’ve ever seen. Peter did such an amazing job here. So here they are:



The names of the apps should be obvious, but for completeness sake, here they are: Localization Manager, Localization Dictionary and Localizer.

I have to say like a few thousand thank-you’s to the great guys over at Boinx Software for sponsoring them! Here’s a link to their site, be sure to check out their fabulous apps!

And at least equally as important is Peter Schlossnikel, the fantastic designer who spent loads of hours and sweat on creating the best possible result. Peter, we’ll have a beer when we meet the next time!

Leave some comments on what you think!
Max

PS: Peter is currently in the verge of finishing up the website design. It’ll probably launch as early as next week. So stay tuned!

05/10: Automatic Resizing

May 10, 2010

Hello all, it’s time again for a roundup on what’s happening to Loc-Suite these days. Very busy days. Very busy days. Basically, I completed my Beleg (like a Bachelor Thesis) about automatic application of layout during localizations. What this means? You will never-ever-ever-again have to manually resize a nib file after localization. Okay, it’s not never, but hopefully many-times ;-)

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…

03/19: Changes and Features

March 19, 2010

It’s about time to post an update on my recent work in the Localization Suite. Lately, I have been implementing a major architectural change that we very long overdue: Switching the database files to a bundle-based format. Here’s the details:

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.

02/21: Editing the Reference Language

February 21, 2010

Up to some weeks ago I have always been convinced that it is absolutely not necessary to be able to edit the reference language from within the Localization Manager. This makes the process very clear: “We create all localizations from the reference files and only read those. We won’t touch them even if you’d want us to.”

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

Contact   Imprint   Home