¿Por qué los recursos de cadena generalmente se mantienen externos al código y no dentro del código?

En general, en muchas plataformas, escribo mis recursos de cadena en un archivo .resx o .xml, y luego los obtengo utilizando un enfoque dependiente de la plataforma.

Es decir, en iOS, los obtengo a través de NSBundle.MainBundle, y al usar Context.Resourcesen Android.

¿Cuáles son las ventajas de este enfoque y por qué no tenerlo directamente accesible en el código? Entonces, por ejemplo:

1. En un proyecto multiplataforma, cualquier plataforma puede acceder a él directamente, sin integración.

2. No hay preocupaciones durante la construcción sobre si los recursos se construyeron bien o no.

3. El codificador puede usar funcionalidades como manejo multilenguaje

Larga historia corta: ¿cuál es la razón por la cual los recursos de cadena están estructurados de esa manera?

[Editar]

Digamos que mi archivo es parte de un proyecto "principal" compartido entre otro proyecto. (Piense en un PCL, estructura de archivo de proyecto multiplataforma).

Y supongamos que mi archivo es totalmente similar a un archivo .resx / .xml, con este aspecto (no soy un profesional en xml, ¡lo siento!): Parámetros Paramètres

Entonces, esto es básicamente un xml personalizado, donde apuntas a la clave / idioma para obtener la cadena adecuada.

El archivo sería parte de la aplicación al igual que agrega cualquier archivo accesible dentro de una aplicación, y el sistema para acceder a los recursos de la cadena, codificados mediante PCL. ¿Esto agregaría una sobrecarga a las aplicaciones?

Localización e internacionalización,

Mantener las cadenas externas les permite cambiar (leer: traducir) sin necesidad de volver a compilar (solo un reenlace a lo sumo, y simplemente dejar caer una nueva carpeta en el mejor de los casos).

Si tiene un archivo que contiene solo los recursos de cadena, puede entregar el archivo de recursos a una agencia de traducción o algo así y obtener una traducción. Supongo que puedes imaginar lo difícil que podría ser eso si tuvieras que darle muchos archivos de código a un laico para hacer alguna traducción (además de tal vez no querer dar tu código a quien sea).

Además de la internacionalización / localización, la separación de cadenas de texto como esta también le permite al corrector de pruebas enviar correcciones a la ortografía / gramática / puntuación que están aisladas messages.${LOCALE}, sin tener que tocar un verdadero archivo de código fuente. Es posible que tenga un apagón en los cambios de código, pero acepte dichas correcciones de texto. Si acepta cambios simultáneos tanto en el código como en los mensajes, mantenerlos separados hace que sea más fácil fusionar los parches, siempre que los cambios en el código no redefinan los mensajes que existían cuando el corrector revisó messages.en_US.

Además, dependiendo de cómo se implemente, puede que ni siquiera sea necesario volver a vincular la aplicación. El código puede simplemente tomar la línea 138 de messages.${LOCALE}un mensaje en particular, con el número de línea determinado en tiempo de ejecución.

Esta es la forma en que su idioma / plataforma ha decidido implementar la localización de cadenas. Todos los enfoques de localización necesitan algún tipo de archivos de recursos externos para obtener las traducciones. El principal problema es cómo mantener estos recursos.

Parece que necesita mantener estos archivos de recursos manualmente , lo que puede ser una gran carga. También complica compartir cadenas repetidas. Y tener que hacer esto cuando actualmente está enviando solo un idioma, es aún más una carga.

Una alternativa común es el enfoque GNU Gettext de simplemente marcar las cadenas traducibles en el código fuente y extraer automáticamente estas cadenas a los archivos PO estándar que funcionan muy bien entre plataformas y lenguajes cruzados. Desde la perspectiva del desarrollador, supera el mantenimiento manual de los archivos de recursos XML cualquier día.