9

En general, sé cómo hacer la localización de las aplicaciones de iOS, lo único es elegir entre las formas disponibles y hacerlo de la manera correcta. Entonces me gustaría preguntarle sobre su enfoque l10n para sus proyectos.Localización para aplicaciones de iPhone: ¿cuál es su enfoque?

Éstos son mis entradas:

  1. tengo 15 archivos (XI ter llenos de un montón de puntos de venta de IB que no se sintetizan como propiedades, sino que que ser localizado).
  2. Es muy probable que mi aplicación tenga 3-5 versiones de idioma, pero es posible que incluso vaya para 10 idiomas en el futuro.
  3. En un futuro próximo planeo agregar nuevos objetivos que pueden cambiar el diseño de la interfaz de usuario (versiones gratuitas/de pago).

Veo dos maneras en que podría ir:

Opción A: localizan cada archivo semilla haciendo XIBs localizable y la adición de versiones lingüísticas:

  1. Temo que con 15 XIBs y 3 -5 idiomas será un horror al mantenimiento que se saldrá de mi control cuando extienda la localización a ~ 10 idiomas e introduzca nuevos objetivos (el horror al mantenimiento no se trata de SCM, estoy usando git btw).
  2. Tendría que mantener sincronizadas todas las versiones de XIB que afectarían en el doloroso proceso de solicitud de cambio.
  3. También me temo que mi paquete de aplicaciones crecerá grande (actualmente los XIB usan ~ 1.1 MB y se traducen a ~ 120 kB de archivos NIB).
  4. cuando decida hacer una versión de iPad, la cantidad de XIB volverá a crecer.

Opción B: hacer la localización en el código cableando todos los enchufes necesarios sintetizarlos a las propiedades y establecer sus etiquetas/títulos correctamente:

  1. Temo que mi aplicación huella de memoria será realmente grande. O, considerando la memoria adecuada, ¿no debería considerar esto como un problema?

Iría por la segunda opción ya que veo menos inconvenientes y puede permitir que todo esté controlado en cada control de vista, pero me gustaría saber cuál sería tu elección. ¿Qué forma funciona mejor para ti?

EDIT: Sé que ibtool podría simplificar el proceso en el Plan A, pero todavía no estoy convencido de ello.

Respuesta

1

Bueno, me esperaba un poco más retroalimentación de modo que los usuarios, pero que está bien ya que después de algunas investigaciones que he hecho mi propia decisión de abandonar la opción B e ir a por una versión modificada de la opción A.

I Usé ideas muy usadas de un Compile-time approach by Philippe Casgrain. En general, usa ibtool para localizar automáticamente las puntas al construir. El enfoque de Philippe mantiene el mantenimiento razonablemente cuerda por el momento. Todas las otras cadenas que utilizo en el código se manejan usando el enfoque NSLocalizedString que fue bastante fácil de implementar en mi caso (solo usé la herramienta genstrings). El único problema que podría afectarme en el futuro es agregar nuevos objetivos con diseños de UI diferentes/modificados.

Es difícil decir si fue la mejor opción. El tiempo lo dirá, así que algún día actualizaré la pregunta y compartiré contigo cómo la decisión funcionó para mí. Tal vez alguien se beneficie de ello en la función;)

3

Estoy utilizando la Opción B en todos mis proyectos, ya que esto también me facilita la distribución de los archivos de cadena a los localizadores. Por supuesto, es necesario realizar pruebas después para asegurarse de que las cuerdas encajen en su lugar. Además, algunos proyectos no utilizan archivos XIB, por lo que el proceso siempre es el mismo, sin importar si se utilizan o no los archivos XIB. No hay problema de memoria con esa opción en absoluto en mi experiencia.

+0

¿Podría optar por la Opción B si sus XIB tuvieran 25 IBOutlets en promedio? Conectarlos a todos, sintetizar y cuidar la gestión de la memoria me resulta tedioso. ¿Cuáles son los motivos para optar por la Opción B? – matm

+0

25 IBOutlets en un solo XIB? Eso parece ser una interfaz de usuario muy concurrida. Gritos para un diseño de interfaz de usuario mejorado;) Pero, en general, no veo una razón para no utilizar archivos de cadenas. Manejar esos muchos XIB y ajustar manualmente todo para cada idioma es una molestia mucho más grande. Si sabe cómo administrar la memoria, no hay inconveniente. – Kerni

+0

Bueno, yo también tomaría la opción B, porque normalmente tiene una salida para un elemento de IU. Excepto tal vez las etiquetas de textFields, pero eso no parece gran cosa. – GorillaPatch

Cuestiones relacionadas