Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

adds support for base internationalization #846

Merged
merged 1 commit into from Mar 12, 2013

Conversation

Projects
None yet
5 participants
Contributor

amccarri commented Mar 11, 2013

If a pod uses base internationalization in it's resources files (.xibs, .storyboards) then this change will make sure external strings files are used when appropriate. Recommended strategy that has worked for me is the following, my podspec contains the following resource line:

  s.resources    = "#{s.name}/**/*.{lproj,png,xib,storyboard}"

With lproj in the resources line, they will be included as folders in the Pods project. While not ideal in that XCode does not recognize them as localization bundles, the change to the script will now instruct ibtool to use the external strings in Base.lproj and the language files rather than assuming the text is hardcoded.

The important thing is that when doing this, do not include *.strings as a resource or it will copy the strings out of the lproj bundles into the root and further confuse XCode.

Owner

fabiopelosin commented Mar 11, 2013

The important thing is that when doing this, do not include *.strings as a resource or it will copy the strings out of the lproj bundles into the root and further confuse XCode.

Did you test to see what happens in that case?

Looks good to me... @alloy what is your take?

--reference-external-strings-file

When combined with the --compile option, this flag indicates that the files in the Base.lproj locale folder should be compiled to reference the matching external strings files found in the other locales when loaded. Available on 10.8 and later.

Contributor

amccarri commented Mar 11, 2013

Yeah, if you include *.strings as part of that resources string, then you will just see all the strings files under your localization bundles show up in the root resources group for that pod. Doesn't really damage anything, app still runs, but I make no guarantees about whether or not i18n works in that case.

Ideally, I would say if you have any external strings that you really do want to copy as normal files, then you should name them explicitly, or put them somewhere else (like you had suggested earlier) where you can add a mask to specifically include them without picking up all the .lproj/.strings files. For example, I have a file called Templates.strings which includes some string resources that don't need to be i18n'd. I just explicitly added that file to my resources list.

Owner

alloy commented Mar 12, 2013

Sounds good to me.

Owner

fabiopelosin commented Mar 12, 2013

Merging it! @amccarri As you have committed a non trivial patch, you can receive push access. If you are interested, just let me know.

@fabiopelosin fabiopelosin added a commit that referenced this pull request Mar 12, 2013

@fabiopelosin fabiopelosin Merge pull request #846 from amccarri/master
adds support for base internationalization
781872d

@fabiopelosin fabiopelosin merged commit 781872d into CocoaPods:master Mar 12, 2013

1 check failed

default The Travis build failed
Details
Contributor

amccarri commented Mar 14, 2013

Yeah I'd be interested in push access, though anything I commit I'll still do pull requests for so it will have benefit of review.

Owner

fabiopelosin commented Mar 14, 2013

Sounds good… granted!

Contributor

onato commented Apr 29, 2013

This breaks my pods with non base i18ned xibs and storyboards. I get the following error on iOS5...

*** Terminating app due to uncaught exception 'NSInvalidUnarchiveOperationException', reason: 'Could not instantiate class named NSLocalizableString'

To get around the error I have to remove --reference-external-strings-file.

Contributor

rivera-ernesto commented May 2, 2013

Same problem as @onato here. From the ibtool man pages:

   --reference-external-strings-file
          When combined with the --compile option, this flag indicates that the files in the Base.lproj locale  folder  should  be
          compiled  to reference the matching external strings files found in the other locales when loaded. Available on 10.8 and
          later.

and seemingly available on iOS 6+ only

Contributor

onato commented May 2, 2013

Yes, base internationalization is iOS6 only.

I added the following Build Phase Script to get around the problem...

sed -i "" 's/--reference-external-strings-file//g' "${SRCROOT}/Pods/Pods-resources.sh"
Contributor

rivera-ernesto commented May 3, 2013

Maybe the best solution would be not to add the option for projects below

platform :ios, "6.0"

Or below OS X 10.8

Contributor

rivera-ernesto commented May 7, 2013

Trying to come up with a solution with #1030

@jzapater jzapater pushed a commit to jzapater/CocoaPods that referenced this pull request Sep 17, 2013

@keith keith Merge pull request #846 from ehuynh/master
uservoice-iphone-sdk 2.0.0
e1302c0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment