Estamos desarrollando una aplicación grande, que consta de muchos paquetes pequeños. Cada paquete tiene su propio conjunto de archivos de recursos para la localización.
¿Cuál es el mejor enfoque para organizar y nombrar las cadenas de localización?
Aquí están mis pensamientos hasta ahora:
Manejo de duplicados
El mismo texto (por ejemplo, "Código postal") puede aparecer varias veces dentro de un paquete determinado. El instinto de programación (DRY) me dice que cree un solo recurso de cadena compartido por todas las apariciones .
De nuevo, un traductor puede querer elegir una traducción larga ("Postleitzahl") en algunos lugares y una más corta ("PLZ") en lugares con menos espacio. O podemos decidir agregarle dos puntos a algunas apariciones ("Código postal:"), pero no a otras. O podemos requerir una mayúscula diferente ("código postal") en algunos lugares. Todos estos argumentos apuntan a crear un recurso por uso, incluso si su contenido es idéntico .
Naming
Si nuestro objetivo es eliminar los duplicados, tiene sentido nombrar los recursos por contenido , tal vez indicando el tipo de uso a través del prefijo. Por lo tanto, podemos tener labelOK
= "OK" , messageFileTooLarge
= "El archivo excede el tamaño máximo del archivo". y labelZipCode
= " Código postal ".
La denominación por contenido tiene la ventaja de manejar los argumentos de formato de forma natural: el recurso messageFileHas_0_MBWhileMaximumIs_1_MB
toma claramente dos argumentos de formato, el tamaño real del archivo y el tamaño máximo del archivo.
Sin embargo, si permitimos duplicados, la nomenclatura por contenido solo no tiene sentido. Para obtener nombres de recursos únicos, de alguna manera debemos incluir el lugar de uso en el nombre del recurso. Eso funciona con los controles gráficos, aunque los identificadores tienden a ser un poco largos: fileSelectionConfirmationButtonText
= "OK" , customerDetailsTableColumnZipCode
= "Código postal" . Sin embargo, para los archivos de código no visual, se hace más difícil. ¿Cómo nombra un uso específico de una cadena si no sabe dónde se mostrará finalmente? ¿Por archivo de código y nombre de función? Me parece bastante torpe y quebradizo.
En general, me inclino por permitir duplicados, pero estoy luchando para encontrar un esquema de nombres coherente que admita esto.
Editar: Esta pregunta tiene dos aspectos: cómo organizar los recursos (DRY vs. duplicados) y cómo nombrarlos . Hasta el momento, las respuestas se han concentrado en el primer aspecto. Apreciaría algunos comentarios con respecto a las convenciones de nomenclatura!