internationalization - repetir - principios de diseño de software dry
No te repitas frente a Internacionalización (6)
Estoy de acuerdo con Mendelt Siebenga cuando dice que debe mantener oraciones enteras o frases en los archivos de recursos de su idioma. Las diferencias en gramática siempre le impedirán realizar reemplazos de una sola palabra en todos los idiomas. Esto aún conducirá a un código menos repetitivo que el primer ejemplo, ya que solo necesita verificar el tipo de objeto y su estado, y luego imprimir el mensaje apropiado del recurso de idioma.
Hace un tiempo estaba leyendo el artículo del W3C sobre " Reutilización de cadenas en el contenido del guión ", que contiene algunos consejos útiles sobre internacionalización, pero que me parece contradictorio con el principio DRY (no repetir) de eliminar el código repetitivo .
Para tomar su ejemplo, podríamos tener un código como este ...
print "The printer is ";
if (printer.working) {
print "on./n";
} else {
print "off./n";
}
print "The stapler is ";
if (stapler.working) {
print "on./n";
} else {
print "off./n";
}
Mi instinto sería eliminar la repetición aproximadamente de la siguiente manera ...
report-state(printer, "printer");
report-state(stapler, "stapler");
function report-state(name, object) {
print "The "+name+" is ";
if (object.working) {
print "on/n";
} else {
print "off/n";
}
}
... pero hacerlo causaría una dificultad en el código si necesitáramos localizarlo en español porque la palabra para ''on'' es aparentemente diferente en esos dos casos.
Entonces, supongo que mi pregunta es, ¿cómo se han acercado otros desarrolladores a equilibrar el principio DRY con la internacionalización de su código?
Una parte de mí quiere argumentar que la internacionalización es una de esas situaciones extremas de programación " no vas a necesitarlo ". Por otro lado, sin embargo, se supone que refactorizar con el principio DRY equilibra esto al facilitar la implementación de la funcionalidad como se requiere, no más difícil que aquí.
Sugeriría usar un CMS en lugar de una codificación rígida en sus valores textuales para cubrir la localización.
Supongo que depende del nivel de calidad del idioma que pretendes alcanzar.
Al tratar de minimizar la repetición del código que trata con estas cadenas de lenguaje real, simplemente se expone a una capa de lógica completamente diferente en las sintaxis y estructuras de diferentes idiomas. Habría una gran cantidad de trabajo involucrado en la producción de código que aún conserva la estructura original del lenguaje mientras se minimiza la repetición.
Tendría que decidir cuál era el enfoque más adecuado para un problema en particular; Código que se repite a sí mismo, o código que intenta ser un Jack of All Trades y acomodar innumerables reglas de lenguaje (sin duda una pesadilla de mantenimiento).
Por supuesto, puede alcanzar un término medio y minimizar la repetición de código, pero renunciar a la elocuencia gramatical satisfactoria. Tomemos el ejemplo de Ultima Online: cuando se localizó, una cadena que decía "Una pila de 329 monedas de oro" se convirtió en algo así como "Una pila de monedas de oro: 329". No es genial, pero es una solución bastante razonable que se presta fácilmente a la localización.
Trataría de mantener oraciones completas en el recurso del idioma. Como dijiste, podrías necesitar diferentes palabras en diferentes contextos. Pero un problema mayor es que el orden de las oraciones puede ser diferente en diferentes idiomas. Entonces, construir cadenas de palabras puede causar problemas.
Solo almacene
The printer is on
The printer is off
The stapler is on
The stapler is off
en el recurso de lenguaje para cada idioma. La repetición aquí es menos un dolor de cabeza de mantenimiento que tratar de averiguar dónde aparecerán todas las palabras sueltas en su aplicación.
Intentamos no crear cadenas de mensajes mediante la manipulación del programa porque el loc. el equipo no puede verlos.
El loc. equipo realmente prefiere mensajes separados pero casi duplicados. Sin embargo, aceptarán mensajes parametrizados.
Por ejemplo, "% (dispositivo)% es% (on_o_off)%".
Los parámetros pueden averiarse, pero al menos es más obvio para el equipo de loc cuando funcionará y cuando no funcionará.
100% de acuerdo con Mendelt.
No es solo un problema de mantenimiento, sino que también puede ser lingüístico. En todos los idiomas latinos, el género, el número y el caso del tema afectan a otros elementos. Ejemplo para rumano
The printer is on: Imprimanta este pornită // feminine
The printer is off: Imprimanta este oprită
The stapler is on: Perforatorul este pornit // masculine
The stapler is off: Perforatorul este oprit
También vea http://www.mihai-nita.net/article.php?artID=20060430a