¿Es seguro usar claves "reales" en NSLocalizedString()? ¿Hay un lenguaje de respaldo garantizado?

Question

Sé que muchos desarrolladores simplemente lo hacen así: comienzan a desarrollar su aplicación en inglés, y ponen NSLoclaizedString(@"Tap this to do that!", @"Telling what to do...") en lugar de simplemente @"Tap this to do that!".

Luego ejecutan genstrings que crea un archivo Localizable.strings de alguna manera extrayendo todas estas cadenas. La parte desordenada: el texto largo utilizado en el código se convierte en la clave. Funciona. Hasta que un día ingresas rápidamente en tu código y cambias la cadena en inglés y te olvidas de la localización y que sirve como la clave para todos esos archivos Localizable.strings.

Por lo tanto, suelo usar teclas "reales" que no se mezclan con cadenas. Para una prueba rápida, creé un proyecto localizado en inglés y francés. Luego configuro el idioma del simulador en alemán. Porque, ya sabes, sería horrible si el usuario alguna vez viera la clave como TTTDT.

Con solo inglés y alemán en su lugar, inicié la aplicación de demostración. Y lo que obtuve fue el texto en inglés del archivo English Localizable.strings.

Conclusión: Parece que NSLocalizedString vuelve al archivo en inglés si el idioma del sistema operativo no está cubierto por la aplicación.

Pregunta: Suponiendo que siempre haya un archivo Localizable.strings (English), y que las claves estén en el archivo junto con los valores formateados correctamente. ¿Hay circunstancias bajo las cuales NSLocalizedString fallaría y luego mostraría la clave directamente?

Answer 1

Para responder a su pregunta: Sí, he experimentado el problema que le preocupa, es decir, los nombres clave aparecieron a pesar de que un archivo localizable.strings estaba presente e incluía entradas para esos nombres clave. Esto sucede cuando tiene más de un archivo localizable.strings en su proyecto. Lo cual puede suceder fácilmente si suelta un conjunto de archivos de un proyecto de código abierto que tiene su propio localizable.strings (como ShareKit) en su proyecto.

Here is a related question que trata este problema.

Pero al menos si usa nombres de teclas estilo ID, notará ese problema cuando pruebe su aplicación en cualquier idioma. Si utilizó la cadena en inglés (o en el idioma base) como las teclas, entonces no verá este problema insidioso hasta que pruebe las versiones localizadas y pueda pasar inadvertido más fácilmente.

Por lo tanto, además de tener que recordar actualizar las claves (en todos los idiomas) al volver a redactar el texto, existe la posibilidad de ocultar errores cuando se utiliza el texto en inglés como clave (el inglés se vería bien, pero localizado versiones no lo harían). Por lo tanto, me parece que usar nombres de teclas "reales" en lugar de texto real es más práctico. Si aún te preocupa que, por alguna razón, aparezcan los nombres clave, elige una clave que sea lo suficientemente descriptiva como para ser comprensible.

Answer 2

Tendemos a utilizar claves "reales", pero generalmente son el texto en inglés (o una forma abreviada) y agregan "Clave" al final. De esa forma está claro.

Answer 3

Escribí un código personalizado que en realidad verifica que todas las teclas de la aplicación aparezcan en todos los archivos localizable.string. Hubo dos pasos para este proceso: usar genstrings para generar un nuevo archivo de cadenas localizables que contenga todas las claves a las que se hace referencia actualmente en el origen. Luego usé algunas API de objetivo C para cargar en mis archivos existentes localizable.strings, y comparé que todos tenían exactamente el mismo conjunto de claves (ni más ni menos) que el nuevo generado.