Skip to content
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

Implement modern locale tag processing #21956

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

nazar-kutz
Copy link
Contributor

@nazar-kutz nazar-kutz commented Feb 22, 2025

Implemented modern IETF BCP 47 locale tag processing

Problem & Initial Fix

The issue we aimed to fix was incorrect parsing of the script in a locale tag. This occurred because the system-provided locale tag used a different format than what our app expected—specifically, it used # instead of + to separate the script from other locale parameters.

A quick fix was introduced in PR #21908, which addressed this formatting issue. However, it assumed that if a script was present, it would always be the third element in the locale tag. This assumption was incorrect, as scripts are optional, and other components like extensions could take the third position instead. Attempting to set an extension as a script in Locale.Builder caused crashes, since scripts must be alpha-4 codes as per ISO 15924 (all possible scripts can be found here (search for "Type: script")).

This issue arose due to a misunderstanding of the locale tag specification and how its components are structured.

Solution

After further investigation, we discovered that Locale.toString() returns locale tags in an outdated format, whereas Locale.toLanguageTag() produces tags compliant with the modern IETF BCP 47 standard.

To resolve this, we made the following changes:

  • Parsing: We now use Locale.forLanguageTag() to correctly interpret locale tags from system settings.
  • Storing: We save the locale in modern BCP 47 format using Locale.toLanguageTag().
  • Backward compatibility: The previous locale handling remains for older Android versions where locale selection is still available within the app.

This ensures:

  1. Proper parsing of system locale settings and avoidance of format inconsistencies.
  2. Reduced complexity when extracting locale parameters.
  3. Stability by preventing crashes due to incorrect script parsing.

Since newer Android versions no longer display an in-app language selection option in OsmAnd (instead relying on system settings), this approach aligns with the platform's expected behavior.

@nazar-kutz nazar-kutz linked an issue Feb 22, 2025 that may be closed by this pull request
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Serbian latin doesn't work
1 participant