I'm also seeing this issue. Frustrating.
stephen_cp
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
From
Berlin
Post
Replies
Boosts
Views
Activity
This isn't working for me. I followed the example given in the video: https://developer.apple.com/videos/play/wwdc2023/10155/?time=1831
And it doesn't detect the default localization, so just shows an empty table. Tools version is 5.9
I even tried renaming the table, so it wouldn't conflict with the main application's Localizable table with no success.
// Catalogs file is then FakeModule.xcstrings
public func printModuleInfo() {
let statement = String(localized: "TestString", table: "FakeModule")
log.info("\(statement)")
}
Here is the package manifest:
// swift-tools-version: 5.9
// The swift-tools-version declares the minimum version of Swift required to build this package.
import PackageDescription
let package = Package(
name: "FakeModule",
defaultLocalization: "en",
platforms: [
.iOS(.v16)
],
products: [
// Products define the executables and libraries a package produces, making them visible to other packages.
.library(
name: "FakeModule",
targets: ["FakeModule"]),
],
targets: [
// Targets are the basic building blocks of a package, defining a module or a test suite.
// Targets can depend on other targets in this package and products from dependencies.
.target(
name: "FakeModule",
dependencies: [],
path: "Sources"
),
.testTarget(
name: "FakeModuleTests",
dependencies: ["FakeModule"]),
]
)
The solution could be a mix of some of these things. I just now discovered that there are 2 ways to import a local package. You can do it via importing from the project inspector and provide a Local... package, or you can just drag the Package.swift file into your project, so that it doesn't look like an installed package dependency, but another target in the "workspace" (which is not a workspace), and then these values start to get populated at build time.
yes it seems super weird that they would not help you identify what's causing the warning. For example, the privacy report (via Organizer > right click on Archive) doesn't indicate much either. For me it just had a listing of a SPM package I'm linking. So do I have to fork that repo and fix it in the package, or does my privacy manifest act as an umbrella for any module in my binary? It's strange that they would just say "fix it" and not really tell you where and what the problem is.