Introduce BUILD_ONLY_KNOWN_LOCALIZATIONS build setting #960
Conversation
… languages added to Localizations in the project when set
Tantalum73
requested review from
aciidgh,
jakepetroules,
kulpreetchilana,
matthewseaman,
mhrawdon,
neonichu and
owenv
as code owners
|
|
||
| knownLocalizations.removeAll(where: { $0 == "Base" }) | ||
| if !knownLocalizations.isEmpty { | ||
| delegate.note("XCStrings will compile languages for known regions: \(knownLocalizations.joined(separator: ", "))") |
There was a problem hiding this comment.
Just heads up that messages like this are going to show up for every xcstrings file, although in this particular case the specific file is not provided. Not saying it needs to be provided, but may appear as duplicate messages. Also for IB Compiler, etc.
There was a problem hiding this comment.
With the changes in 9764b31 where a source location added to the message, they might look like duplicates at first, but double clicking the entry will open the corresponding source file.
Thanks for pointing that out!
Sources/SWBCore/FileToBuild.swift
Outdated
| } | ||
|
|
||
| // This region is not supported, so it shouldn't build. | ||
| delegate?.note("Skipping .lproj directory '\(regionVariantName).lproj' because '\(regionVariantName)' is not in project's known localizations (BUILD_ONLY_KNOWN_LOCALIZATIONS is enabled)") |
There was a problem hiding this comment.
Might want to look into specifying file paths for diagnostics like this. I don't mean in the message, but rather as part of the diag instance.
There was a problem hiding this comment.
Sure! By doing this, a double click on the log message will automatically open the source file, neat!
| return true | ||
| } | ||
|
|
||
| if regionVariantName == "mul" { |
There was a problem hiding this comment.
Base will be included in the list of known languages if using Base internationalization. I think no special rules need to apply to Base here.
|
@swift-ci test |
2 participants
This PR introduces a build setting
BUILD_ONLY_KNOWN_LOCALIZATIONS. Only languages explicitly added to the project's "Localizations" will be built when set.The new build setting allows developers to have work-in-progress translations in their project, which don't get built.
In the old world with only
.stringsfiles, it was possible to have partial translations in files that were on disk, but not referenced in the Xcode project. When localization was complete, they were simply added as a reference, and then they started contributing to the build.Since String Catalogs contain all localizations in a single file, it was not possible to not build content for a given language, making this workflow more complicated to achieve.
This build setting fixes that. When set, only languages in the list of "Localizations" in the project settings are built – including String Catalog content.
Now, for the time that a new language is brought up that isn't fully translated yet, developers enable
BUILD_ONLY_KNOWN_LOCALIZATIONS, and remove that language from the list of Localizations. The work on this language can continue, and when it's ready to ship they add it back to the list, or disableBUILD_ONLY_KNOWN_LOCALIZATIONS.