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

18

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?

cross-platform resources internationalization Léon Pelletier
fuente
posible duplicado de la internacionalización: ¿en qué pensar?
mosquito
66
No, mis preocupaciones no son sobre la internacionalización, y más bien sobre arquitectura y multiplataforma, lo siento.
Léon Pelletier
1
Esta pregunta puede generalizarse a cualquier tipo de recurso, realmente, incluso con la facilidad de localización / internacionalización a un lado. ¿Cuáles son las ventajas de mantener cualquier tipo de recurso separado del código? ¿Por qué las imágenes o los archivos de audio generalmente no están codificados en la fuente como cadenas binarias? (Los URI de datos existen, por supuesto, pero generalmente no son prácticos para archivos grandes). Otros ya han proporcionado algunas respuestas bastante buenas, pero solo quería señalar que las cadenas legibles por el usuario no son el único tipo de recurso que se beneficia de ser externalizado.
JAB

Respuestas:

38

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).

monstruo de trinquete
fuente
Este reenlace vs recompilar es una buena razón, gracias.
Léon Pelletier
2
Sigue siendo la única persona que entendió la pregunta.
Léon Pelletier
3
@ratchetfreak es una mala forma aceptar demasiado pronto (en cuestión de horas definitivamente cuenta). No da tiempo para que surjan otras respuestas. Esto es simple, preciso y preciso ... pero alguien podría aportar una respuesta mejor, más completa y más detallada mañana (o el mes que viene).
WernerCD
3
Extra: puede estar bien que un traductor edite un archivo XML, pero nunca los deje
tocar el
Ahora la pregunta es: "¿Esta respuesta aún se aplica a los idiomas interpretados?". Pregunto porque no habría ninguna vinculación o recompilación.
Thomas Eding
10

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).

Flo
fuente
2
Bueno, no hay diferencia entre un archivo que se incluye en el proyecto y un archivo de recursos. El problema no está ahí.
Léon Pelletier
Estoy hablando de incluir los recursos directamente en el código y luego manejar todo dentro del programa, por lo que es más compatible con PCL / multiplataforma.
Léon Pelletier
2
si tiene un archivo de "código" con todos sus recursos de cadena (definición de diccionario o algo así) y nada más en él ... bueno, básicamente es un archivo de recursos (pero uno para una única plataforma, como por ejemplo, Android no lo hará) tomar cualquier código de objetivo-c). Si hay otro código o si está dividido en varios archivos, es más difícil obtener una traducción externa. En una vista multiplataforma, un formato de texto como xml tiene la ventaja de que puedes leerlo y usarlo en cualquier idioma / plataforma (pero es posible que tengas que ponerlo a trabajar)
Flo
7

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.

Monty Harder
fuente
0

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.

Rene Saarsoo
fuente