To complete a pluralized Mac app label, add plural variations in Xcode, supply every category needed by each supported localization, and test the rendered results. This walkthrough uses a synthetic item-selection message.

The task is to finish one count-dependent label in a SwiftUI Mac app. The message reports how many items are selected, accepts a nonnegative integer, and preserves that meaning across translations. The workflow combines category coverage, placeholder checks, and runtime tests so that a filled catalog entry has a clear acceptance standard.

What does complete plural coverage require?

Apple recommends String Catalogs for plural localization in Xcode 15 and later. Its plural documentation distinguishes a required fallback from grammatical completeness: other is mandatory in a strings dictionary, but omitting additional language-specific categories can produce incorrect grammar. English requires one and other; its zero category is optional. Localizing strings that contain plurals.

The possible category names are zero, one, two, few, many, and other. They describe language-dependent grammatical groupings, rather than six numeric ranges shared by every language. A category named one should not become a universal application rule that checks only whether the count equals one. Unicode defines categories through changes that numbers require in a phrase, including changes beyond the noun itself. Plural Rules.

For this task, use the following message contract. These are illustrative application requirements, not requirements imposed by Apple.

Contract field Requirement for this example
Message key selection.count
English default value \(count) items selected
Input One nonnegative Swift Int named count
Meaning Number of currently selected items
Output One complete localized label containing the count
Coverage Every supported localization, including the source localization
Acceptance Required categories supplied, numeric substitution preserved, representative outputs checked

Requiring the number to appear is a deliberate choice for this label. Apple permits plural variants that spell out a number or omit the numeric format specifier. A different message contract could allow that. Here, keeping the count visible makes it easier to compare the label with the selection it describes. Localizing strings that contain plurals.

Connect the Swift message to the catalog

Swift’s String.LocalizationValue supports localizable text with runtime interpolation. When a stable identifier should differ from the English source text, Apple directs developers to a String initializer with a separate defaultValue. That fits selection.count: the identifier names the message, while its default value supplies the English wording. String.LocalizationValue.

For a small test app, create a macOS app project using SwiftUI in Xcode 15 or later, with a macOS deployment target of 12 or later. Replace the generated app entry file with the complete program below; keep only one @main declaration in the target. Add Localizable.xcstrings to the app target before following the catalog steps. The program requires Xcode and the macOS SDK; it was not compiled in this research environment.

import Foundation
import SwiftUI

@main
struct PluralSampleApp: App {
    var body: some Scene {
        WindowGroup {
            PluralSampleView()
        }
    }
}

struct PluralSampleView: View {
    @State private var count: Int = 1

    private let samples: [Int] = [
        0, 1, 2, 3, 4, 5, 10, 11, 12,
        20, 21, 22, 100, 101, 102, 1_000_000
    ]

    private var selectionLabel: String {
        String(
            localized: "selection.count",
            defaultValue: "\(count) items selected",
            comment: "Selection summary. The integer is the number of selected items. Keep the count visible in every plural variant."
        )
    }

    var body: some View {
        VStack(alignment: .leading, spacing: 16) {
            Picker("Sample count", selection: $count) {
                ForEach(samples, id: \.self) { value in
                    Text(verbatim: String(value)).tag(value)
                }
            }

            Text(verbatim: selectionLabel)
        }
        .padding(24)
        .frame(minWidth: 360)
    }
}

The numeric picker entries are test inputs. The localized summary is resolved by String(localized:defaultValue:comment:), then displayed as the resulting string. Apple documents that the initializer’s first argument supplies the lookup key, its default value supplies the source text, and comments provide translation context. Xcode extracts strings passed through localizable APIs during a build. Preparing your app’s text for translation.

Keep the integer inside the localizable interpolation. For this contract, do not prebuild separate English singular and plural sentences in application branches. Keeping one message gives the catalog one clear responsibility: selecting the appropriate localized wording for the supplied count.

Supply the categories for every supported localization

Use Xcode’s editor to create the variation structure:

  1. Choose Product > Build to populate the catalog.
  2. Open Localizable.xcstrings and select the source localization.
  3. Control-click selection.count and choose Vary by Plural.
  4. Fill each source-language variation.
  5. Add supported localizations using the sidebar’s Add button, then fill their variations.

Xcode adds language-specific plural forms and determines the interpolation’s format specifier. Applying plural variation to the source localization keeps the variation structure synchronized across languages; applying it only to another localization affects that localization alone. Localizing and varying text with a string catalog.

For this integer interpolation, the English entries can be:

English category Catalog value
one %lld item selected
other %lld items selected

Use the specifier generated by Xcode for the actual interpolation type. Apple’s documented integer example uses %lld; copying a different placeholder into a translation can break the argument contract. Xcode initially prepopulates variation fields with the key’s value, so inspect the wording in every field. Localizing and varying text with a string catalog.

Build a coverage worksheet with one row per actual localization identifier. Record the categories Xcode generates for this message, whether each has finished text, and which inputs you will test. Using the project’s real identifiers prevents a broad language label from concealing an unreviewed localization.

Do not copy the English category set into every row. Likewise, do not demand all six categories everywhere. Let the catalog provide the working structure, then consult the language’s cardinal plural rules when selecting test inputs. Cardinal rules concern quantities; ordinal rules concern positions and answer a different question. Unicode documents these as separate rule types. Unicode Technical Standard #35: Numbers.

Validate structure, placeholders, and rendered text separately

Use three checks because each answers a different question. A missing category is a coverage problem; an incorrect placeholder is a formatting problem; an awkward sentence is a wording problem. Recording them separately makes the next correction clear.

Check category coverage

For every worksheet row, compare the expected categories with the populated catalog entries. Confirm that other exists and that no expected category contains an empty value or an unfinished copy of the source text.

For a simple completeness check, define the expected set as the categories generated for that localization plus any intentional supported override. The missing set is the expected set minus the categories containing finished text. Any missing member leaves the message unfinished under this article’s acceptance standard. This is a practical review method derived from the documented variation workflow, rather than a claim that Xcode enforces this exact checklist.

If two categories legitimately have identical wording, keep that wording where needed and review both entries. The goal is to preserve the message’s meaning across the required categories; visible differences between every pair of strings are unnecessary.

Check the numeric substitution

Build and review catalog diagnostics. Apple documents String Catalog validation for common problems such as mismatched format specifiers. Resolve those diagnostics, then inspect whether each variant still meets this message’s requirement to display the count. Build multilingual-ready apps.

For this single-argument example, ask whether the numeric placeholder is present, still numeric, and inserted once in the intended place. A successful build is useful evidence, but the acceptance decision also needs category coverage and actual rendered text.

Test representative counts in the Mac app

Choose Product > Scheme > Edit Scheme, select Run, and open Options. Set App Language and the applicable App Region, close the dialog, and run the Mac app. Repeat for every supported localization. Apple documents this scheme-based procedure for testing localized output. Testing localizations when running your app.

The sample picker provides a starting set of counts, not universal category coverage. Add values appropriate to each localization before treating its test row as complete.

Test choice What it checks
0, 1, and 2 Empty, single-item, and small multiple-item selections
At least one representative input per required category Coverage of the localization’s grammatical distinctions
Values on either side of relevant rule boundaries Category changes beyond the smallest counts
A large valid count Numeric substitution and available label space
Every tested input Meaning, complete wording, and the visible count

Unicode’s rules associate categories with conditions and sample values; numeric details, including fractional digits, can matter. This contract accepts integers only. If the application later accepts decimal quantities, revise the interpolation, source wording, and tests together instead of assuming the integer results still establish coverage. Unicode Technical Standard #35: Numbers.

Diagnose an unexpected result

Use the observed symptom to choose the next inspection:

Symptom Next action
selection.count is absent from the catalog Build again and inspect the localizable call and selected table
Only one localization has plural variations Revisit where Vary by Plural was applied
A variant still has English plural wording Inspect the prepopulated field and supply its finished translation
The displayed number is missing or malformed Compare the variant’s placeholder with Xcode’s generated specifier and the message contract
A larger count uses unexpected wording Check that localization’s category rule and add a representative test
Correct wording does not fit Adjust the view and retest the complete label

For an older project using Xcode before version 15, Apple’s supported path uses .strings and .stringsdict resources. The plural dictionary supplies language-specific variants and requires other; it does not remove the need to supply the remaining categories needed for correct grammar. Localizing strings that contain plurals.

Finish the message when every supported localization has a completed coverage row, its placeholders satisfy the contract, and representative counts produce the intended label in the running app. Revisit those rows whenever the supported localizations, numeric input type, or message meaning changes.

Sources