Although the number of changed lines is not small, it's because XIB format was changed when I saved XIB without any changes in Xcode 5.
Would it be easier for you to review/merge if I split logic changes from UI changes?

hmm...I reverted XIB files, and still investigating how to change XIB files without changing root elements from to . Still no luck, nor any clue from Google either. Just open and save in my Xcode changes its root element.

But anyway, I hope now it's easier to have a look at what were really changed. I'll look further into how I can add menu and preferences UI without changing XIB root elements, but if you would like to take the logic changes from this pull request and do the UI changes by yourself, please feel free to do so.

Oh, great, by undoing my changes and merging recent changes in the develop branch, I found May 23 and June 8 commits change the XIB root elements from <archive> to <document>. I can now make reasonable changes against the develop branch.

Menu and preferences changes were done, except resizing and layout for Hotkeys panel. Doing that will touch several lines in XIB and I guess it will make harder to review the pull request, so I'm wondering whether I should include that in this pull request or not...

BTW, if you took the pull request #138 first, this pull request will conflict. I can merge if you do so, and the diff of XIBs in this patch will be smaller.

Thank you for the response. Great. I'll merge #138 to this.

Done, merged and pushed.

Amazing! Do you think you could merge this into 1.6.1 branch? I know that this is not the right practice with git flow, but the reason is that I just merged the Japanese localization and there will be some strings to translate :-)

I'm looking into this. Merging to your preferred branch is fine with me.
However, well, honestly speaking I don't have much experiences on localizations of iOS apps, but as far as I looked at the changes quickly with some help from Google, localizations brings a bit of complexity to IB files.
Simple localization in Xcode duplicates all IB files and it looks like it's all manual process to change all duplicated XIB files in sync, and we're here right now. So from now on for any changes anyone makes to IB files, someone has to maintain its Japanese copy.
There's a standard tool, ibtool, to extract strings from XIB, and write localized strings back, which looks better way to go to me, but googling it points out some different issues with the process.
I heard Xcode 6 improves localization process but I'm not familiar with it yet.
So...hmm, this is a bit more complicated than originally thought. I'll look into it a bit further.

Still learning, but a few findings:

• Base localization looks better approach.
• There are 3, not 2, localization files: en, ja, and English. It looks like English isn't used at all and is safe to remove, but needs further double-check.
• At least one connection in XIB was removed during the localization. Probably need to revert that, and still checking other possible errors.

Thanks a lot for looking into this! This and next week I'm on a conference so I won't have a chance check this.

np, I wanted to learn Mac/iOS localization process someday, so this was a good opportunity. And I'm no hurry at all, please take your time. Your response is appreciated whenever you want to work on.

After some further investigations, however, I've got quite a bit unfortunate conclusion. In short, my recommendation is to revert the Japanese localization for now, and then wait a little more for Apple to come up with better localization process.

Here's a longer version. The most basic and traditional iOS/Mac localization process is what ShiftIt is currently using. However, a lot on the web--everyone I've seen on the web--recommend to avoid using that process as much as possible. Since the process involves forking XIB files, with 10 XIB files in a project and 10 languages to localize, you'll end up maintaining 100 XIB files in sync, with proper layouts and proper connections from XIB to Objective-C. ShiftIt has only two, and one is menu, so it's not that hard, but it's still quite hard. All new text won't appear in non-English versions until someone updates localized XIB files. All connections you made in XIB won't work in non-English versions, so the program may stop working properly. Someone needs to keep track of changes in English version and then manually apply the same changes to localized XIB files. There is no good solution to mitigate this pain if you go this way, and Apple is going to a different way as I'll explain later in this post.

The other method I saw on the web is to make localizations one-off process. Whenever a release is made, begin localization process from scratch. You could re-use some text from old string files, but you'll need to take the current English XIB files, duplicate them, and find a way to re-apply localized text. As you can imagine, this isn't great either.

So, the answer is not to fork XIB files. Most people are building a toolchain and process to extract all user-facing strings from XIB files, localize them, and write them back to their projects. Apple only provides basic building blocks, such as ibtool and AppleGlot, but does not provide a complete solution yet, so you'll need to build your own by yourself.

Some people, especially for language that tends to be much longer than English such as Germany or Spanish, cannot localize without changing layouts. Such people either ends up localizing XIB (but then keeps doing re-localize on every release) or to do strings-only localization along with building their in-house code to automagically fix layouts.

Apple's answer to this problem, as far as I understand, is to use auto-layout. Auto-layout is rather new, especially on iOS (introduced in iOS6,) but Apple is enhancing auto-layout on both OS X and iOS and recommends applications to adopt to it to make localizations easier.

Apple's answer to the other problem, how to extract user-facing strings from XIB and write them back, is in Xcode 6. Xcode 6 provides a feature to export all localizable strings to XLIFF, an industry standard file format for localization, hand it off to localizers, and import localized XLIFF back to the project. So things would be better with Xcode 6.

There is one more issue, which I couldn't find answers yet, and from which the current ShiftIt is suffered, is that Apple does not have a fallback system to any languages but the key strings. So if French users for instance run ShiftIt, they might see "AUTHORIZATION_INFORMATIVE_TEXT_10_9" on their screen. Again as far as I understand today, you have to either:

1. Localize all strings to all possible languages your users are using so that nobody would see the key strings.
2. Use English text for the key, so that displaying the key is ok. This, however, involves pain where whenever there was a typo in English text, you have to modify all localized string files.
3. Don't know if this is possible or not, but add some in-house code to fallback to English localization if the users' system is in languages that are not localized yet.

I don't know if near-future Xcode provides a solution to this issue or not, but Xcode 6 will provide a solution to toolchain/process issue, so at least two out of three issues down in near future.

I'm rather new to Apple platforms, and I'm a bit surprised how immature its localization system is as of today. It might work if I'm serious about localizations and can pay a lot of costs to it, but there's no easy-and-low-cost localization solutions yet. Microsoft platforms do have such system in place, but it looks like Apple is trying to improve a lot right now, so I'd recommend to wait a bit more.

What do you think?

Thanks for the research. I took a bit of a time over the lunch break to have a look into this as it is quite interesting. Indeed, it is quite striking that the process is rather unnatural.

I tend to agree with you that the whole i18n brings quite a bit of an overhead, but I did not wanted to drop it since @hkurosawa has put quite a bit of an effort into providing the Japanese localization. I guess a reasonable option is in using "base i18n" which basically means having one XIB file and all the strings externalized in additional .strings files. I tried to use it and the result is in the 07fbdb3 commit. Please have a look at it and if you find it usable (and working - perhaps there is something I miss), I'd be very happy if you could merge your changes in. Thanks a lot!

Oh, superb, I wasn't aware that Localizable Strings is available in Xcode 5. This looks much better than I suggested, thank you for following up during your busy conference and this finding.
I'll look into further.

Made another pull request (#142) for XIB regression issues since it might make reviewing diffs easier. I'll work on merging/re-basing this pull request after you confirmed all these possible regressions and made decisions which ones to take, as I guess changing XIB further might make reviewing previous changes harder.

Merged with the pull request #142 assuming you like it, but then the diff got hard to look as this pull request is still based on develop. I'll create another pull request.