18

Generally, on many platforms, I'm writing my string resources to a .resx or .xml file, and then I'm getting them using some platform-dependent approach.

That is, on iOS, I'm getting them via NSBundle.MainBundle, and by using Context.Resources on Android.

What are the advantages of this approach, and why not having it directly accessible in the code, so, for example:

  1. In a cross-platform project, any platform can access it directly, with no integration.

  2. There are no concerns during building about whether or not the resources built well.

  3. The coder can use functionalities such as multilanguage handling

Long story short: what is the reason why string resources are structured that way?

[Edit]

Let's say that my file is part of a "core" project shared between other project. (Think about a PCL, cross-platform project file structure.)

And suppose that my file is just totally similar to a .resx/.xml file, looking like this (I'm not a pro in xml, sorry!): Parameters Paramètres

So, this is basically a custom xml, where you point to the key/language to get the proper string.

The file would be part of the application just like you add any accessible file inside an app, and the system to access the string resources, coded using PCL. Would this add an overhead to the applications?

Improve this question
3
  • possible duplicate of Internationalization : What things to think about?
    – gnat
    Mar 10, 2014 at 14:18
  • 6
    Nope, my concerns aren't about Internationalization, and rather about architecture and cross-platform, sorry.
    – Léon Pelletier
    Mar 10, 2014 at 14:41
  • 1
    This question can be generalized to any sort of resource, really, even with ease of localization/internationalization aside. What are the advantages of keeping any sort of resource separate from code? Why aren't images or audio files usually encoded in the source as binary strings? (Data URIs do exist, of course, but are generally impractical for large files). Others have provided some pretty good answers already, but I just wanted to point out that user-readable strings aren't the only resource type that gains a benefit from being externalized.
    – JAB
    Mar 10, 2014 at 16:33

4 Answers 4

Reset to default
37

Localization and internationalization,

Keeping the strings external allows them to change (read: translated) without needing to recompile (just a relink at most, and just dropping in a new folder at best).

Improve this answer
5
  • This relink vs recompile is a good reason, thanks.
    – Léon Pelletier
    Mar 10, 2014 at 12:45
  • 2
    Still the only person who understood the question.
    – Léon Pelletier
    Mar 10, 2014 at 14:45
  • 3
    @ratchetfreak it's bad form to accept too soon (within hours definitely counts.) Doesn't give time for other answers to bubble up. This is simple, and to the point and accurate... but someone might bring in a better more complete, more detailed answer tomorrow (or next month for that matter).
    – WernerCD
    Mar 10, 2014 at 17:08
  • 3
    Extra: It may be ok for a translator to edit an XML file, but don't ever let them fiddle near actual code...
    – Darkhogg
    Mar 10, 2014 at 20:33
  • Now the question is: "Does this answer still apply for interpreted languages?". I ask because there would be no relinking or recompiling.
    – Thomas Eding
    Mar 14, 2014 at 20:22
10

If you have a file that contains only the string resources then you can give the resource file to a translation-agency or something like that and get a translation. I guess you can imagine how hard that could get if you would have to give a lot of codefiles to a layperson to do some translation (in addition to maybe not wanting to give out your code to whomever).

Improve this answer
3
  • 2
    Well, there is no difference between a file that is included in the project and a resource file. The problem is not there.
    – Léon Pelletier
    Mar 10, 2014 at 14:42
  • I'm talking about including the resources directly in the code and then handling everything inside the program, so it is more PCL/Cross-platform friendly.
    – Léon Pelletier
    Mar 10, 2014 at 14:43
  • 2
    if you have a "code" file with all your string resources (dictionary definiton or something like that) and nothing else in it .. well than it basically is a resource file (but one for a single platform, as eg. android will not take any objective-c code). If there is other code in it or if it is split over several files than getting external translation is harder. In a cross-platform view, a text-format like xml has the advantage that you could read and use in on any language/platform (but you might have to to put some work it)
    – Flo
    Mar 10, 2014 at 21:36
7

In addition to internationalization/localization, separating text strings out like this also allows a proofreader to submit corrections to spelling/grammar/punctuation that are isolated to, messages.${LOCALE}, without having to touch a true source code file. You might have a blackout on code changes but accept such text corrections. If you are accepting concurrent changes to both code and messages, keeping them separated makes it easier to merge the patches, provided that the code changes don't redefine any messages that existed when the proofreader checked out messages.en_US.

Also, depending on how it's implemented, it may not even be necessary to relink the application. The code may simply grab line 138 from messages.${LOCALE} for a particular message, with the line number being determined at run time.

Improve this answer
0

This is just the way that your language/platform has decided to implement localization of strings. All approaches to localization need some kind of external resource files to get the translations from. The main pain point is how you maintain these resources.

Looks like you need to maintain these resource files manually, which can be quite a burden. It also complicates the sharing of repeated strings. And having to do this when you're currently shipping only one language, is even more of a burden.

A common alternative is the GNU Gettext approach of just marking up the translatable strings in source code and automatically extracting these strings to standard PO files which work nicely cross-platform and cross-languages. From a developer perspective it beats the manual maintenance of XML resource files any day.

Improve this answer

Your Answer

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

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