Estoy (como todos los demás) usandoNSLocalizedStringpara localizar mi aplicación.

Desafortunadamente, hay varios "inconvenientes" (no necesariamente por culpa de NSLocalizedString), incluido

No hay autocompletado para cadenas en Xcode. Esto hace que trabajar no solo sea propenso a errores, sino que también sea tedioso.Puede terminar redefiniendo una cadena simplemente porque no sabía que ya existía una cadena equivalente (es decir, "Ingrese la contraseña" frente a "Ingrese la contraseña primero")e manera similar al problema de autocompletado, debe "recordar" / copiar las cadenas de comentarios, o biengenstring terminará con múltiples comentarios para una cadenaSi quieres usargenstring después de que ya haya localizado algunas cadenas, debe tener cuidado de no perder sus antiguas localizaciones.Las mismas cadenas están dispersas en todo su proyecto. Por ejemplo, usasteNSLocalizedString(@"Abort", @"Cancel action") en todas partes, y luego Code Review le pide que cambie el nombre de la cadena aNSLocalizedString(@"Cancel", @"Cancel action") para que el código sea más coherente.

Lo que hago (y después de algunas búsquedas en SO, pensé que muchas personas hacen esto) es tener un @ separastrings.h archivo donde yo#define todo el código de localización. Por ejempl

// In strings.h
#define NSLS_COMMON_CANCEL NSLocalizedString(@"Cancel", nil)
// Somewhere else
NSLog(@"%@", NSLS_COMMON_CANCEL);

Esencialmente, proporciona la finalización del código, un lugar único para cambiar los nombres de las variables (por lo que ya no es necesario usar una cadena de caracteres) y una palabra clave única para refactorizar automáticamente. Sin embargo, esto tiene el costo de terminar con un montón de#define declaraciones que no están inherentemente estructuradas (es decir, como LocString.Common.Cancel o algo así).

Entonces, aunque esto funciona bastante bien, me preguntaba cómo lo hacen en sus proyectos. ¿Existen otros enfoques para simplificar el uso de NSLocalizedString? ¿Existe quizás un marco que lo encapsule?