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 handlingLong 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  ParamtresSo, 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?
Why are string resources generally kept external to the code and not inside the code?
cross platform;resources;internationalization
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).