I just started doing android development stuff after getting pretty comfortable with Java. Android apps tend to do this weird thing where they have all strings for their program held in an XML file called strings and the program refers to the strings instead of string literals in the code or even String objects.

The only reason I can think of to do this is internationalization. Is that it? What are the advantages/disadvantages of this approach? Should I be employing it in my other programming endeavors (such as regular Java)?

Seems like an unnecessary level of abstraction.

3 Answers 3


The reason Android puts strings in separate XML files is for localization.

Should you do it? Yes. Even if your app will support only one language, you never know if you'll be supporting others in the future, in which case you would only need to add another XML file.

This is not weird at all, it is actually the rule.

All platforms have some sort of mechanism like this. Microsoft's .Net platform uses .resx files, Android uses .xml files and "regular Java" uses .properties files (see the docs).

  • +1 "it's not weird at all". Correct, I mean "Externalize Strings" refactoring is in eclipse since... always?
    – Lovis
    Commented Jan 14, 2015 at 8:02

According to this stackoverflow question the reason for the strings in XML is for localization.

Should you do this in your other endeavours? The hard line answer is probably yes. That said, my gut tells me, if you're only going to deploy in one language then possibly it's a premature optimization. So my answer is a hard maybe.

  • 2
    It allows you to change text without recompiling the program. That can be really nice when you discover a typo in production.
    – user53141
    Commented Jan 14, 2015 at 0:49
  • 1
    Also, while it might be premature optimization if you are not planning on doing internationalization, but if you have a very large codebase it is going to take a LOT of work to add this in later. Requirements change. Our CEO sold our product to a large customer in Denmark, then came to us saying "The app is all translatable right?". It wasn't. Fortunately that was a legacy system that has almost been replaced by something that is. Commented Jan 14, 2015 at 0:53
  • Are there any other things that are pooled like this typically?
    – Bassinator
    Commented Jan 14, 2015 at 1:39
  • This is not premature optimization. If anything, it's YAGNI. ;-) One could argue that it's premature optimization to don't do localization for the sake of development-time/performance or whatever.
    – Lovis
    Commented Jan 14, 2015 at 8:09

If it's only about localisation then there would be many 'regular' Java applications where this wouldn't be necessary, or even helpful. In cases where the program uses strings that won't be displayed to humans then multiple languages won't be important. An example of this would be where strings are used to build text based protocols to talk to external systems that expect a specific language for the syntax of the protocol messages e.g. JSON.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.