Swift
Completed
-
Section 1: Getting Started
-
Section 2: Core Syntax
-
Section 3: Optionals
-
Section 4: Object-Oriented and Value Types
-
Section 5: Memory Management
-
Section 6: Generics and Error Handling
-
Section 7: Concurrency
-
Section 8: Working with Collections
-
Section 9: Codable and Data Handling
-
Section 10: Protocol-Oriented Programming
-
Section 11: Testing and Tooling
-
Section 12: Practical Projects
-
Section 13: Interview Practice
-
Section 14: More Practice Exercises
-
Section 15: More Standard Library
-
Section 16: Advanced Concurrency
-
Section 17: Foundation Framework Deep Dive
-
Section 18: URLSession and Networking Deep Dive
-
Section 19: Combine Framework
-
Section 20: SwiftUI Fundamentals for Swift Developers
-
Section 21: Server-Side Swift with Vapor
-
Section 22: Swift Package Manager Deep Dive
-
Section 23: Swift Concurrency Deep Dive
-
Section 24: More Language Features
-
Section 25: Error Handling Deep Dive
-
Section 26: Testing Deep Dive
-
Section 27: Data Structures and Algorithms in Swift
-
Section 28: More Practice Exercises
-
Section 29: More Interview Practice
-
Section 30: Swift Macros (Swift 5.9+)
-
Section 31: Property Wrappers Ecosystem
-
Section 32: Swift Interop Deep Dive
-
Section 33: iOS App Architecture Patterns
-
Section 34: Performance and Debugging
-
Section 35: App Distribution and CI/CD
-
Section 36: More Practical Projects
-
Section 37: SwiftData and Persistence
-
Section 38: More Design Patterns
-
Section 39: More Review and Practice
-
Section 40: More Foundation Deep Dive
-
Section 41: Advanced Collections in Swift
-
Section 42: Advanced Generics Practice
-
Section 43: UIKit for Legacy and Hybrid Apps
-
Section 44: watchOS and visionOS Development Basics
-
Section 45: More Networking Patterns
-
Section 46: More Testing Practice
-
Section 47: Accessibility in Swift Apps
-
Section 48: Localization
-
Section 49: More Practical Projects Round 2
-
Section 50: Swift Charts Framework
-
Section 51: More Interview and Algorithm Practice
-
Section 52: Final Practice and Mastery
-
Section 53: Swift Compiler and Build System
-
Section 54: More Concurrency Practice
-
Section 55: App Store Guidelines and Review
-
Section 56: More Design and Architecture
209: Pluralization Rules with Localization
You've probably already handled basic translation by putting strings in a Localizable.strings file. That works great for "Settings" or "Logout," but it falls apart the moment you have to deal with counts. In English, we only have two forms: singular and plural. But if you're targeting a language like Arabic or Polish, you might have six different plural forms depending on the number. If you try to handle that in your Swift code, you'll end up with a nightmare of if/else blocks that make your view controllers unreadable.
The temptation of the ternary operator
When I first started building apps, I used to take the "quick and dirty" approach. Let's say we're building a notification center and we want to show how many unread messages a user has. I'd likely write something like this:
let count = 5
let message = count == 1 ? "You have \(count) unread notification" : "You have \(count) unread notifications"
notificationLabel.text = NSLocalizedString(message, comment: "")
It looks clean for English, right? But I quickly realized I made a huge mistake here. By putting the logic in the Swift code, I've hardcoded the English pluralization rule. If a translator wants to localize this for a language where "zero" is treated differently than "many," they can't. They're stuck with my ternary logic. We need to move the "decision" of which string to use out of the code and into the localization system itself.
Moving the logic into a stringsdict file
To do this properly, we use a .stringsdict file. Think of this as a specialized dictionary that tells iOS: "Based on this number, pick the correct version of this sentence."
First, I'll create a file named Localizable.stringsdict. In Xcode, this is essentially an XML file, but the editor gives us a nice table to work with. I'll define a key called "unread_notifications_count"`.
Inside that key, I'll set the "Plural Kind" to Right-to-Left (if applicable) or simply Offset, but usually, we use Plural. Then I can define the specific rules:
- One: "You have %d unread notification"
- Other: "You have %d unread notifications"
I'll also add a Zero case here, because "You have 0 unread notifications" feels a bit robotic. I'd rather it say "You're all caught up!"
Wiring it up in the view
Now that the logic lives in the .stringsdict file, the Swift code becomes incredibly simple. I no longer care if the count is 1, 0, or 1,000. I just pass the number to the localization function, and the system handles the rest.
let count = 0
// The system looks at the .stringsdict file and picks the 'Zero' string automatically
let formatString = NSLocalizedString("unread_notifications_count", comment: "Notification count message")
notificationLabel.text = String.localizedStringWithFormat(formatString, count)
By using String.localizedStringWithFormat, we're telling Swift to look for a variable substitution (the %d we put in the dictionary) and use the value of count to determine which plural rule to apply. It's a much more professional way to handle it, and it keeps your UI logic separated from your linguistic logic.
📋 Practical Task
Implement Pluralization for a Shopping Cart
You are building a shopping cart summary screen. Currently, the app uses a simple string that looks awkward when there is only one item (e.g., "1 items in your cart").
Your Task:
- Create a hypothetical
Localizable.stringsdictentry for the key"cart_item_count". - Define three rules for this key:
- Zero: "Your cart is empty"
- One: "You have %d item in your cart"
- Other: "You have %d items in your cart"
- Write the Swift code required to fetch this localized string and inject a variable named
itemCountinto it usingString.localizedStringWithFormat.
There are no comments for now.