What steps will reproduce the problem?
Given a gyp file with a target like:
{
'target_name': 'WatchApp',
'product_name': 'WatchApp',
'type': 'executable',
'mac_bundle': 1,
'ios_watch_app': 1,
'mac_bundle_resources': [
'WatchApp/Images.xcassets',
'WatchApp/Base.lproj/Interface.storyboard',
'<!@(find WatchApp/*.lproj -type f -name "InfoPlist.strings")',
'<!@(find WatchApp/*.lproj -type f -name "Interface.strings")',
'<!@(find WatchApp/*.lproj -type f -name "Localizable.strings")',
],
'sources': [
'WatchApp/AppInfo.plist',
],
'xcode_settings': {
'ASSETCATALOG_COMPILER_APPICON_NAME': 'AppIcon',
'INFOPLIST_FILE': 'WatchApp/AppInfo.plist',
'IPHONEOS_DEPLOYMENT_TARGET': '8.2',
'SKIP_INSTALL': 'YES',
'COPY_PHASE_STRIP': 'NO',
'TARGETED_DEVICE_FAMILY': '4',
'TARGETED_DEVICE_FAMILY[sdk=iphonesimulator*]': '1,4',
},
},
And input directories in the file system:
Base.lproj with: Interface.storyboard
en.lproj with: Interface.strings: Localizable.strings InfoPlist.strings
fr.lproj with: Interface.strings: Localizable.strings InfoPlist.strings
What is the expected output?
The generated Xcode project has Localizable.strings
What do you see instead?
EFD7D2B7F8E1A98C63486EAF /* Localizable.strings */ = {
isa = PBXVariantGroup;
children = (
03D630A109123736EA8D2CA5 /* en */,
BAD2A34301459C7B86E00DF1 /* fr */,
);
...
FAD9A92EC0A79349966AABE7 /* Interface.storyboard */ = {
isa = PBXVariantGroup;
children = (
60D8968FAA6DA94C05F54C79 /* Base */,
);
name = Interface.storyboard;
sourceTree = "<group>";
};
...
That is, gyp correctly generates each separate XX.lproj as a member of the
'children' list of Localizable.strings, or InfoPlist.strings, but it fails to
do it with .xib and .storyboard files.
This causes the built binary to not be correctly localized when run in one of
the other languages that should be supported.
What version of the product are you using? On what operating system?
OS X 10.10.3
Please provide any additional information below.
Original issue reported on code.google.com by oster@google.com on 17 Apr 2015 at 9:11
Original issue reported on code.google.com by
oster@google.com
on 17 Apr 2015 at 9:11