Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@app/src/main/java/me/capcom/smsgateway/helpers/LocaleHelper.kt`:
- Around line 11-23: Change the fallback behavior so the app can preserve a
"system default" option: in onAttach(...) use an empty string "" as the fallback
when calling getPersistedData instead of Locale.getDefault().language; when you
need the actual device/system locale (not the app's current Locale), obtain it
via Resources.getSystem().configuration.locales[0]; construct locales from
stored language tags using Locale.forLanguageTag(...) rather than Locale(String)
so both empty (system) and concrete values are handled robustly; ensure
setLocale(...) / persist(...) only writes concrete language tags (non-empty) and
that updateResources(...) uses the system-locale from Resources.getSystem() when
the stored language is empty.

In `@app/src/main/java/me/capcom/smsgateway/ui/SettingsFragment.kt`:
- Around line 38-44: The language change handler in SettingsFragment uses
findPreference and its OnPreferenceChangeListener to restart MainActivity before
the new language is persisted; update the listener to immediately persist/apply
the selected locale by calling LocaleHelper.setLocale(requireContext(), newValue
as String) (or equivalent) inside the listener before creating the Intent to
restart MainActivity, then restart via MainActivity Intent and finish the
activity so the restarted activity reads the updated locale.

---

Nitpick comments:
In `@app/src/main/java/me/capcom/smsgateway/App.kt`:
- Line 37: Remove the redundant LocaleHelper.onAttach(this) call inside the
App.onCreate method; attachBaseContext already calls LocaleHelper.onAttach and
returns the adjusted Context, so delete the extra invocation in onCreate (the
line calling LocaleHelper.onAttach(this)) to avoid a duplicate/no-op call while
leaving attachBaseContext and its LocaleHelper usage intact.

In `@app/src/main/java/me/capcom/smsgateway/helpers/LocaleHelper.kt`:
- Line 37: The locale construction using Locale(language) in LocaleHelper (the
locale variable assignment) won’t parse BCP-47 tags like "en-US" correctly;
replace it with Locale.forLanguageTag(language) when language is non-empty (and
keep Locale.getDefault() fallback) so region/script variants are handled
robustly by the code that constructs the locale.

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@app/src/main/java/me/capcom/smsgateway/helpers/SettingsHelper.kt`:
- Around line 31-36: The language getter in SettingsHelper should normalize the
empty-string sentinel stored under APP_LANGUAGE so callers don't need to handle
it: update the language property's getter (var language: String) to retrieve
settings.getString(APP_LANGUAGE, null) and if the result is null or isEmpty()
return Locale.getDefault().language; keep the setter as-is. This centralizes
handling of the "" sentinel used by language_values and avoids coupling with
LocaleHelper.updateResources.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@app/src/main/java/me/capcom/smsgateway/helpers/SettingsHelper.kt`:
- Around line 31-40: The getter for the language property currently maps stored
"" and "system" to Locale.getDefault().language, which causes
LocaleHelper.setLocale(...) to persist a fixed locale and lose dynamic system
behavior; change the logic in the language getter (property in SettingsHelper)
so only null falls back to Locale.getDefault().language while returning the raw
stored value for "" and "system" (i.e., if stored is null ->
Locale.getDefault().language, else return stored) so the "system" preference is
preserved and not rewritten.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@app/src/main/res/values-ar/strings.xml`:
- Line 96: Update the Arabic translation for the string resource named
settings_start_on_boot: replace the current value "بدء التشغيل عند بناء النظام"
with a more accurate phrase for "start on boot", e.g. "بدء التشغيل عند إقلاع
النظام", so the string XML entry for settings_start_on_boot reflects the correct
Arabic wording.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@app/src/main/res/values-ar/strings.xml`:
- Around line 137-139: The Arabic resource strings incoming_sms_messages,
incoming_data_messages, and incoming_mms_messages are still in English; update
their values to proper Arabic translations while preserving the integer
placeholder (%1$d) and order (do not alter %1$d token), and ensure the
translations are natural and RTL-friendly (e.g., use appropriate Arabic words
for "SMS", "Data SMS", and "MMS"); edit the values of string
name="incoming_sms_messages", string name="incoming_data_messages", and string
name="incoming_mms_messages" in the Arabic strings.xml accordingly.

Verify each finding against the current code and only fix it if needed.

Duplicate comments:
In `@app/src/main/res/values-ar/strings.xml`:
- Around line 137-139: The three string resources incoming_sms_messages,
incoming_data_messages, and incoming_mms_messages in values-ar/strings.xml are
still in English; replace their text with proper Arabic translations while
preserving the numeric format specifier (%1$d) and punctuation/spacing (e.g.,
"رسائل SMS: %1$d" or preferred Arabic phrasing) so the Arabic locale shows fully
localized labels for SMS, Data SMS and MMS counters.