Correctly localize XIBs

[GoogleCodeExporter]

I noticed that lproj folder were simply copied XIBs. This is not a good way to 
approach XIB localization, because every time you make only little change to 
the XIBs, you have to go in *all* lproj folders and manually change XIBs in the 
same way, which is *extremely* boring and error-prone.

The correct way to handle XIB localization is to extract strings in a .strings 
files and then use the "ibtool --strings-file <strings file> --write <out XIB> 
<base XIB>" command to merge localized strings with the base XIB.

Original issue reported on code.google.com by hsoft@hardcoded.net on 12 Nov 2010 at 9:38

[GoogleCodeExporter]

hsoft, I have to confess that I am a noob when it comes to localization. Will 
see what I can do. Since localization is a bit low on my prio list, this might 
take a little.

Original comment by rbur...@gmail.com on 12 Nov 2010 at 11:39

• Changed state: Accepted

[GoogleCodeExporter]

Its priority should be higher, now that TT has 3 localizations. Now, whenever 
you make a change in an XIB, it's 3 places where you have to make that change 
in again, and make sure you didn't forget trivial stuff like bindings and 
stuff. Imagine if you have 10 localizations... Changing XIBs, however small is 
the change, will soon become a nightmare.

The basic principles behind the .strings files are pretty simple, it's just a 
matter of reading the docs, which doesn't take that much time.

Original comment by hsoft@hardcoded.net on 12 Nov 2010 at 11:53

[GoogleCodeExporter]

As I mentioned to Rainer, the proposed concept has a drawback that I do not 
know a solution for, but perhaps you do: Translating from English to German 
produces (on average) 20% more text. To accomodate that, I had changed the size 
of some German XIB elements to allow for the additional space. Now, unless 
there is a straightforward way to have a XIB distribute space dynamically in 
such cases (e.g. when creating the localized XIBs from the base version), I am 
unsure if the results will look good. The German might have to be very 
condensed or the English look like there is too much empty space...
Though, I agree that the proposed method takes less time. .strings files are 
easy indeed and I used them as much as possible when introducing German strings 
in code-generated UI (as opposed to pre-created XIBs).
Of course, it might also be possible to just create the whole UI 
programmatically instead of using XIBs and let the code take care of both, 
spacing / positioning AND localization at the same time, but that sounds like a 
major change to the existing code.

Martin

Original comment by martin.w...@googlemail.com on 12 Nov 2010 at 12:28

[GoogleCodeExporter]

There is indeed sometimes a problem with longer strings not fitting in the 
layout sometimes, although when I did localization for my own app, it was a 
rather rare occurrence. When it happened, if the missing space was small, I 
enlarged the window/button/whatever in the base XIB to fit everything (since 
the missing space was small), and when it was large, I asked the translator 
(myself or my german friend) to abbreviate.

What you can also do is to, after you've re-generated your translated XIB, you 
go over them and see if you have to do some language-specific enlargements. 
It's a pain, but it is still less of a pain then having to make all changes to 
your XIBs manually, like what happens in the current situation. And, the most 
important: if you make a mistake (likely), you only get a label that is not big 
enough to fit everything. In the current situation, if you make a mistake, you 
can possibly get a crash (missing binding, stuff like that). When I look at 
Transmit's changelog and see stuff like "Fixed crash for German translation", I 
think "Oh god, they're doing their localization wrong".

There seem to be programmatic solutions for this problem (The guy from 
Delicious monster had a blog post about this a while ago), but they're 
certainly overkill for TT.

Original comment by hsoft@hardcoded.net on 12 Nov 2010 at 1:03

[GoogleCodeExporter]

That is what I thought. OK, well, I guess it won't hurt to try and do the 
following (Rainer, please let me know if this is ok for you as well):
Let's enlarge the base (e.g. English) XIB a bit and see if perhaps it still 
looks ok when it has enough space to also provide for the German strings?
Then, there'd be two tasks for whoever does a localization to any language:
- Translate all the .strings files into the respective language
- Every time there is a new release, check the generated and localized XIB 
(e.g. I'd check the German one) if the XIB layout needs fiddling with.

That way, we could make use of hsoft's suggestion and at the same time ensure 
that the translated app still looks good. Because to my mind, that is just as 
important as a good translation.

Any additional ideas?

Martin

Original comment by martin.w...@googlemail.com on 12 Nov 2010 at 3:56