Skip to content

Locale.preferredLocales #1291

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
77 changes: 77 additions & 0 deletions Proposals/0026-preferredLocales.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,77 @@
# Locale.preferredLocales

* Proposal: [SF-0026](0026-preferredLocales.md)
* Authors: [करन मिश्र · Karan Miśra](https://github.com/karan-misra)
* Review Manager: TBD
* Status: **Awaiting review**
* Review: ([pitch](https://forums.swift.org/...))

## Introduction

Add `Locale.preferredLocales` as an alternative to `Locale.preferredLanguages` that returns `[Locale]` instead of `[String]`.

## Motivation

Currently, `Locale.preferredLanguages` is the only way to retrieve the list of languages that the user has specified in Language & Region settings. This follows its predecessor `+[NSLocale preferredLanguages]` and returns an array of `String`s instead of `Locale`s. Processing and manipulating strings is complex and errorprone for clients.

This proposal introduces `Locale.preferredLocales` as a way to retrieve the same information, but in the form of an array of `Locale`s which will allow clients to use the information more easily and with fewer errors, specifically when used to customize the presentation of data within their apps such that content in the user’s preferred languages is more prominent.

## Proposed solution

We propose adding `preferredLocales` as a static variable on `Locale`, similarly to `preferredLanguages`. One of the primary use cases is to allow apps to build language selection menus in which the user’s preferred locales are bubbled up to the top. This can be achieved with the proposed `preferredLocales` API as follows:

```swift
// When building a language selection menu, `matchedLocales` would be shown at the top, and `otherLocales` would be shown below, with a visual divider.
var matchedLocales = []
var otherLocales = []
let availableLocales = // ... array of Locale objects ...
for locale in availableLocales {
var foundMatch = false
for preferredLocale in preferredLocales {
if locale.language.isEquivalent(to: preferredLocale.language) {
matchedLocales.append(locale)
foundMatch = true
break
}
}
if !foundMatch {
otherLocales.append(locale)
}
}
```

## Detailed design

```swift
public struct Locale : Hashable, Equatable, Sendable {

/// Returns a list of the user’s preferred locales, as specified in Language & Region settings, taking into account any per-app language overrides.
@available(FoundationPreview 6.2, *)
public static var preferredLocales: [Locale]
}
```

## Source compatibility

There is no impact on source compatibility or existing code.

## Implications on adoption

This feature can be freely adopted and un-adopted in source code with no deployment constraints and without affecting source compatibility.

## Future directions

In order to further support the use case of building language selection UIs, we can consider adding convenience functions on `Locale` that allow sorting and splitting a list of available `Locale`s into `preferred` and `remaining`, which can then be used to directly populate the UI.

```swift
public static func sorted(_ available: [Locale]) -> (preferred: [Locale], remaining: [Locale])
```

We can also consider adding APIs that work with `Locale.Language` in addition to `Locale` since in many use cases, the developer is handling a list of languages does not need the additional functionality in `Locale`.

Lastly, we can choose to deprecate `Locale.preferredLanguages` since it returns the same information but using `String` which is not a good container for a language identifier and leads to incorrect usage.

## Alternatives considered

* Naming-wise, another possibility was `Locale.preferred`. However, following the current naming convention, this would be confused as returning `Locale` and not `[Locale]`. Additionally, it would be best to keep `Locale.preferred` open in case we need a way to get the first, most preferred `Locale` in the future.
* Deprecate `preferredLanguages` and encourage developers to only use `preferredLocales`.