When I first formed the idea that evolved into Linguan it was because it was a tedious process to edit strings files with text editors and never being sure if you translated everything. In school my Latin teacher told us (incorrectly) that Ecstacy comes from ex (“out of”) and tease (“cause pain”) and that is what Ecstasy really means: to be without pain.
Many years later I was reminded of that because it was a pain (you know where) to deal with translations, especially if you had more than one extra language or had to deal with translators. As soon as you update your app with some new features you instantly lose track what additional tokens which of the translators has to provide a translation for.
Linguan comes to the rescue for all of us pained developers. It’s basically a very smart editor for .strings files. Plus a validator that is able to find inconsistencies and for example if you saved a strings file as UTF8. Plus an export and merge function that lets you send all untranslated tokens of specific languages to translators and merge their results back into your project. And you can even tell your translator to get Linguan because it gives him a nice interface to work through the strings files you send him.
Linguan was my first app on the Mac app store and it was created under a partnership with BytePoets. The reason for this was that I am harboring the notion that more can achieved through partnerships than just by yourself. And the result speaks for itself.
The first user to voice his ecstasy was Joe Carney who has localization for 41 languages in one app he is working on. You can imagine his surprise about all the missing translations that Linguan informed him about.
Linguan validates your project and tells you about:
- if a file is UTF8 instead of UTF16. iOS ignores UTF8 strings files and might cause a bad surprise if you find that your translations don’t show up.
- if a token is translated several times. In this case it is not clear which translation is actually being used by the app.
- if a token is not translated, i.e. missing a translation. Here iOS will fall back to using the token name itself, which might be “LOGIN_EMAIL” and look quite weird on a button.
Contrary to what I initially believed the comment you put in front of a token is not used as a primary key. So if you have the same token under two different comments then these are still the same.
I have seen two ways to use comments in projects and Linguan supports both. First you can use comments to tell the translator about the context that this string is used in because sometimes that might cause him to translate it differently. For this scenario all the comments would be different and verbose. The second method that I personally prefer is to group multiple tokens (e.g. from one view controller) under one comment. Linguan is able to show you either all tokens or group them by comment. The latter option obviously only makes sense if you use the second modus operandi.
For short texts you probably want to use the table grid view for translating. But there is also a Wizard mode that has bigger boxes if you have longer texts or multiple lines of text.
Linguan is designed to work for the developer as well as the translator. As such you have two modes, one is to open an xcodeproj which will parse the project file and show you a tree of your strings files. The other is to open a single strings file. We want you to recommend to your translators to use Linguan as well because then they won’t mess up the file structure of text file and you can easily merge in their changes.
This is where Linguan is truly amazing. It adds meta-information to the strings file that lets it know from which source file certain tokens originated from. So you could have multiple strings files in your project and have your Spanish translator deal with these in one go. Then when you merge that back into your project all new translations are put where they belong.
If you want to add new languages then you have to do that in Xcode before going into Linguan. The reason for this is that we parse the project file, but we don’t dare to modify it yet. A new localization means that Xcode adds a new lproj folder and copies all localized files into that. For the initial release version we decided against such risky endeavors.
Bear in mind that this is version 1.0. So it is possible that you find something that’s not working as expected or that you can think of features that would be nice to have. Hey “real artists ship” and so we did.
We believe that Linguan provides a piece of functionality that should have been provided by Apple, but wasn’t. So we tried to make a tool thats worthy of being mentioned with Xcode on the same breath. Check it out on the Mac App Store. If you find any issues or have feature requests then you can use our bug tracker for that.