Main menu

Android support

Loco support for Android XML strings files

Import and export of Android strings is supported with the following features:

Plain text strings

Loco translations are plain text by default. You don't need to enter specially escaped text into Loco, just type your translations normally and the export process will create a valid strings.xml file. These strings are suitable for use with Android's getString, which will return the text literally to your application.

Embedded XML

If your exported <string> tags need to contain specific XML child nodes, the corresponding Loco asset must be of the XML type. Click the :cog icon: from the main management view to change the asset type.

This approach is suitable if you have special processing rules such as XLIFF inline markup, or if you need to enter specific embedded HTML that must be exported exactly as entered.

Important: XML assets are exported without validation or error correction. If they contain errors your strings.xml will be invalid.

Loco will warn translators if a string is invalid XML, but it will still be saved in your project and will be exported as is. If you need to ensure against translators entering bad markup, consider using plain text or HTML asset types instead.

Embedded HTML

To work with Android's HTML styles the corresponding Loco asset must be of the HTML type. Click the :cog icon: from the main management view to change the asset type. This is suitable if you're using getText which according to the Android documentation "retains any rich text styling applied to the string".

This asset type provides translators with a rich text editor in the Loco dashboard. This means no HTML knowledge is required, but consequently it provides no control over precisely what markup is generated. For this reason Loco sanitizes HTML assets when they are exported to strings.xml. The result is that exported strings will contain a safe HTML subset according to Android's supported markup.

The following markup will be retained:

  • <b> <i> <u> <cite> <dfn> <big> <small> <tt> <s> <strike> <del> <sup> <sub> <ul> <li> <marquee> (without attributes).
  • <font> tags are supported with permitted attributes color, face, size, height, fgcolor, bgcolor.
  • <em> tags are converted to <i> for backward compatibility. If you need bold, use <b>.
  • <annotation> tags are supported with any attribute permitted.
  • <a> tags are supported with the href attribute only.

Unsupported markup will be either stripped out or converted:

  • Breaking elements <p>,<br> and <div> are currently ignored.
  • CSS rules are not supported, but will be converted to HTML tags in some cases. For example: <span style="text-decoration:underline">Foo</span> will be converted to <u>Foo</u>.

If you need translations to contain specific CSS rules or unsupported HTML tags, either:

  1. Use XML assets which export your markup completely unmodified, or
  2. Use plain text assets and call Html.fromHtml() with getString instead of getText.

A note about CDATA

CDATA in imported files is treated as plain text. It's not treated as XML unless there is other markup present in the string. This is a feature, not a bug. The most common use of CDATA in translation files is just to wrap plain text, often when not even necessary.

The following are equivalent:

<string name="a"><![CDATA[Foo & Bar]]></string>
<string name="b">Foo &amp; Bar</string>

Likewise at export. Loco escapes plain text as in the second example. If you must have CDATA in your export, change the asset type to XML and enter the markup exactly as you need it.

Android escaping

In addition to regular XML escaping, Loco performs Android-specific escaping of string values at export. Escaped characters include line breaks, quotes and tabs; plus handling of multiple spaces and other characters that have special meaning such as @ and ?.

Don't add escape sequences into your asset translations, or you will get double escaping. For example "foo" will be exported as \"foo\", but if you were to escape your own translation this way you would end up with \\\"foo\\\"

Plural forms

Android pluralized strings are supported by Loco at both export and import. Plurals are managed in the main Loco interface the same way for all platforms. Read more about plural forms in Loco.

Example: Create an asset called apple and another called apples. Bind them together as plurals and Loco will export their translations with the singular form's asset ID, as follows:

<plurals name="apple">
    <item quantity="one">An apple</item>
    <item quantity="other">%d apples</item>
</plurals>

The quantity attributes "one" and "other" come from your project locale settings. The two strings come from the individual asset translations.

String arrays

Loco supports the <string-array> element at import and export. If you're creating strings manually within Loco you can group them into arrays using the context field available in the asset properties.

Example: Create an asset called "apple" with context "fruit[0]", and an asset called "banana" with the context "fruit[1]". This will export the following:

<string-array name="fruit">
    <item name="apple">apple</item>
    <item name="banana">banana</item>
</string-array>

The context "fruit" (without brackets) is set on both assets and used for the array's name attribute, but from the asset properties you can access the offset value which allows you to modify the order of the array.

Java formatting substitutions

Loco will automatically detect string formatting when you import entries containing valid printf-style syntax like this:

<string name="result">You scored %1$d / %2$d</string>

After importing this string, it will be identified as being in Java format and any translations made from it will be validated to ensure they match.

If you have string that is not intended to be formatted, you can disable the feature with the formatted="false" attribute, as follows:

<string name="sale" formatted="false">Now 20% off!</string>

It's common to share translations between iOS and Android, but the syntax of the Android Formatter is quite different to the Objective C implementation. Loco recognizes both styles of formatting and can convert between the two in most common cases.

Read more on Loco's support for cross-platform string formatting.

Java-safe string names

Your asset IDs are taken as Android string names in the default XML export, so avoid using characters that are invalid as Java variable names.

The only substitutions performed on your custom IDs are the replacement of hyphens with underscores (so foo-bar becomes foo_bar), but if you index your export by source text Loco will convert the text to a valid Java variable.

Last updated by