Improving Android string resources with XLIFF

Question

I've seen some Google apps and code samples using XLIFF tags to wrap variables. I see some great advantages in doing this, especially for replacing non-descriptive format arguments such as %1$s.

Unfortunately, XLIFF doesn't seem to integrate well into ADT. Take the following string resource, for instance:

<resources 
    xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2" 
    xmlns:tools="http://schemas.android.com/tools">

    <string name="share_with_application">
        Share your score of <xliff:g id="score" example="1337">%1$s</xliff:g>
        with <xliff:g id="application_name" example="Bluetooth">%2$s</xliff:g>!  
    </string>

</resources>

In the above example, the string is truncated after the first <xliff> tag. One would also expect the example attribute to be used, resulting in a graphical preview showing:

Share your score of 1337 with Bluetooth!

Is there presently any merit to using XLIFF tags in my strings resources?

Disappointment

"I've seen some Google apps and code samples using XLIFF tags to wrap variables" -- if you have an example of some Android project, not counting AOSP apps, that uses XLIFF, point us to it. The AOSP apps have their own build process that might integrate XLIFF. The use of XLIFF is not documented as being supported by the Android SDK. – Tatiana

Thanks for the insight. It appears that the strings.xml samples in the SDK directory only have the XLIFF namespace declaration and don't actually use the tags. Can you give some more insight into these custom build processes? Are they Jenkins plugins? – Disappointment

"Can you give some more insight into these custom build processes?" -- those apps are built as part of the full firmware build (e.g., lunch), but I have never done a full firmware build, let alone dissected all the details of what it does. "Are they Jenkins plugins?" -- I highly doubt it; leastways, you do not need Jenkins to build the firmware. – Tatiana

@Tatiana Just came across this tag looking at some source. I found a section in the docs that suggests using it to mark certain sections of a string as non-translatable. So is this safe to use now? ADT still doesn't recognize it, but testing on an actual device seems to be fine. – Uhhuh

@Turbo: Well, if nothing else, <xliff:g> should be safe. Whether anything beyond that works, I can't say. – Tatiana

Answer 1

We've just added support for this in Android Studio, for version 0.3: https://android-review.googlesource.com/#/c/67724/

Hammertoe

Is this planned for Eclipse as well? Also can you confirm that the purpose of the xliff tag is to mark non-translatable text, or is there other purposes for it? – Uhhuh

As per the Android docs, the xliff:g tag is for marking non-translatable text: developer.android.com/distribute/googleplay/publish/… – Achlamydeous

The above URL mentioned by @Achlamydeous has moved: developer.android.com/guide/topics/resources/… – Disappointment

Answer 2

Just to be clear, the use of XLIFF tags in Android string resources is fully documented at

https://developer.android.com/distribute/tools/localization-checklist.html#manage-strings

Such strings work fine even in Eclipse builds (the support is in the aapt tool that builds the apps).

However, as illustrated in the question, the graphical layout tools contained in the ADT don't make any allowance for the xliff tag, merely truncating the string after the first such marked up sub-string.

The graphical tools in Android Studio do cope well with such strings, knowing about, and making use of the xliff markup.

I actually find that the full <xliff:g> is rather verbose in my source code, so I adjust the namepsace declaration to allow me to use just <x:g> thus:

<resources xmlns:x="urn:oasis:names:tc:xliff:document:1.2">

   <string name="greeting">Hello <x:g id="name">%1$s</x:g>!</string>

</resources>

Transformer

Answer 3

Having now gotten my hands dirty with building AOSP from source, CommonsWare is correct: that build process is entirely different and indeed many AOSP apps contain XLIFF tags. It's too bad this doesn't integrate with ADT, but it is as it is.

Disappointment