Android App Internationalization: Problems and Solutions

Internationalization (i18n) and localization (L10n) in Android are achieved by naming resources with language and region qualifiers (e.g., zh_CN ). Android does not provide a dedicated API; instead, developers reference resources using the R.resource_type.resource_name pattern in Java and @string/name in XML.

The main workflow for app internationalization includes:

Collecting hard‑coded strings and moving them into strings.xml . Create language‑specific folders such as values_en , values_zh , etc., and let the system replace the strings automatically.

Using Android Studio’s Lint inspections to locate hard‑coded text. Configure a custom inspection profile (Preferences > Inspections) and enable Android > Lint > Internationalization > Hardcoded text and TextView Internationalization . Run Analyze > Inspect Code to generate a list of hard‑coded strings.

When Lint misses some cases (e.g., setText("My test") ), use a regular expression such as setText\(.*"\) to find remaining occurrences.

Annotate methods with resource‑type annotations ( @StringRes , @DrawableRes , @DimenRes , @ColorRes ) to help Lint detect indirect usages.

Replace string concatenation with formatted strings. In Java use String.format("Name is %s, age is %d", name, age) and in strings.xml use placeholders like %1$s and %2$d (or the newer $s syntax) to keep the text translatable.

Escape special XML characters (e.g., &#34; for double quotes, &#38; for ampersand, &#60; for <, &#62; for >, \n for newline).

To hand the strings to translators, export strings.xml to an Excel sheet, remove XML tags, split columns, sort, and de‑duplicate using Excel formulas such as =IF(COUNTIF(B$1:B1,B1)>1,"重复","") . After translation, generate a new strings.xml by concatenating columns with a formula like ="<string name=\""&A1&"\">"&C1&"</string>" , then place the files into the appropriate language‑specific resource directories.

Language switching at runtime requires updating the Resources configuration:

Resources resources = getResources();
DisplayMetrics dm = resources.getDisplayMetrics();
Configuration config = resources.getConfiguration();
config.locale = Locale.US; // user‑selected locale
resources.updateConfiguration(config, dm);

Because the UI does not refresh automatically, three common approaches are:

Override onConfigurationChanged (declare android:configChanges="locale" in the manifest) and manually refresh text views.

Call recreate() on the activity after a language change (note the extra onSaveInstanceState / onRestoreInstanceState calls and possible flicker).

Clear the activity stack and start the main activity again: Intent intent = new Intent(this, MainActivity.class); intent.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TASK|Intent.FLAG_ACTIVITY_NEW_TASK); startActivity(intent); finish();

Persist the selected language using SharedPreferences and apply it in the application’s onCreate() (e.g., via a LanguageUtil.applyUserLocale() helper). Also guard against system‑language changes by checking if the app language differs from the system language and forcing the app’s locale when needed.

UI adaptation issues after importing translated strings include:

Layout position problems – move fixed dimensions to values_en/dimens.xml or use wrap_content .

Overly long English text – ask translators to keep strings concise, use abbreviations, or adjust font size/dimensions.

All‑caps button text – the default AppCompat theme sets textAllCaps=true . Override it in a custom theme or set android:textAllCaps="false" on individual buttons.

Overall, Android app internationalization is less about complex technology and more about systematic text handling, automation, and consistent coding practices.