Inconsistency Between Translation API Language Identifiers and Foundation Locale

Question

Created 3w

Replies 1

Boosts 0

Participants 2

I recently noticed an inconsistency in how languages are represented in Apple’s new Translation API compared to Foundation’s Locale system.

Observation from the Translation API

When retrieving the list of supported languages using:

let availableLanguages = try await LanguageAvailability().supportedLanguages

The results are:

Language(components: Foundation.Locale.Language.Components(languageCode: Optional(uk), script: nil, region: Optional(UA)))
Language(components: Foundation.Locale.Language.Components(languageCode: Optional(zh), script: nil, region: Optional(TW)))
Language(components: Foundation.Locale.Language.Components(languageCode: Optional(ko), script: nil, region: Optional(KR)))
Language(components: Foundation.Locale.Language.Components(languageCode: Optional(en), script: nil, region: Optional(GB)))
Language(components: Foundation.Locale.Language.Components(languageCode: Optional(de), script: nil, region: Optional(DE)))
Language(components: Foundation.Locale.Language.Components(languageCode: Optional(zh), script: nil, region: Optional(CN)))
Language(components: Foundation.Locale.Language.Components(languageCode: Optional(ja), script: nil, region: Optional(JP)))
Language(components: Foundation.Locale.Language.Components(languageCode: Optional(id), script: nil, region: Optional(ID)))
Language(components: Foundation.Locale.Language.Components(languageCode: Optional(nl), script: nil, region: Optional(NL)))
....

Key points: • The script component is always nil. • Region codes (CN, TW, etc.) determine the script for languages like Chinese (Simplified or Traditional). • Other languages (e.g., en-GB, en-US, pt-BR) also rely on region-based identification.

Observation from Foundation Locale (Locale.current.language)

When retrieving the user’s system language setting:

systemLanguageObj = Locale.current.language

I get a different format where the script component is present, but the region may vary based on user settings. This means that mapping between script and region is not consistent between the two APIs, requiring manual handling.

My key questions: 1. Is my current approach correct, or is there a better way to get user language settings that match Translation API identifiers? 2. If no alternative exists, could the Translation API align its language identification method with Foundation Locale to reduce ambiguity?

Any insights or suggestions would be greatly appreciated!

Boost

Answer 1

Frameworks Engineer OP

Apple

3w

Can you share more details about what you’re trying to accomplish?

There are certain APIs like isEquivalent(to:) (link) that would allow comparing Locale objects. With that said, with better knowledge of your use case, there might be a more specific suggestion that can be employed.

0