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:
-
In a cross-platform project, any platform can access it directly, with no integration.
-
There are no concerns during building about whether or not the resources built well.
- 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?
3
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).
5
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).
3
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.
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.