Estructuración de archivos de traducción de sitios web.

Enfrenté este problema varias veces mientras construía sitios web. Explicaré el uso de PHP y Laravel como ejemplo, pero este problema es muy común entre varias plataformas. Esto ya se abordó en algunas preguntas ( post1 , post2 , post3 , post4 y algunas otras) pero las publicaciones realmente no obtuvieron una buena respuesta.

La pregunta es: ¿Cuál es la mejor manera de estructurar el contenido traducido dentro de los archivos de idioma?

Actualmente estoy usando Laravel (no menciono la versión porque tanto Laravel 4 como Laravel 5 tienen funcionalidades de localización similares, al menos lo suficientemente similares para los propósitos de este tema).

La localización estructura el contenido a través de los archivos de idioma (en, es, de, fr …) dentro de los cuales puede haber varios archivos .php que contienen una statement de retorno que devuelve una estructura de diccionario de varios niveles.

/lang /en messages.php /es messages.php 

y los archivos contienen algo como esto:

  'example message for value exaple-key', 'example2' => [ 'sub-example' => 'example message for example1.sub.example', ], ]; 

y llamando a esto se hace haciendo algo como esto:

 //Laravel 5 trans('messages.example1'); //outputs 'example message for value exaple-key' trans('messages.example2.sub-example'); //outputs 'example message for example1.sub.example' //Laravel 4 Lang::get('messages.example1'); //outputs 'example message for value exaple-key' Lang::get('messages.example2.sub-example'); //outputs 'example message for example1.sub.example' 

Algunos métodos de agrupación vienen a la mente:

  1. por contenido del sitio web

    ejemplo: homepage.php, page1.php, page2.php...

  2. por dominio lógico:

    ejemplo: auth.php, validation.php, pagination.php...

  3. por html:

    ejemplo: buttons.php, popup_messages.php, form_data.php...

  4. por traducción directa:

    ejemplo: simple_words.php, phrases.php... y que contienen contenido como 'password-to-short' => 'your password is to long'

  5. Algunos híbridos / combinación de los mencionados anteriormente.

Todos estos tienen algunos beneficios obvios e inconvenientes y no intentaré ir a eso, pero la quinta opción es probablemente la mejor solución, pero aún existe el problema de dónde trazar la línea para obtener una duplicación mínima de frases y contenido.

Otro problema es cómo resolver el problema de los primeros caracteres en mayúscula en algunos casos y en minúsculas en otros casos, así como los caracteres de puntuación en los extremos.

Me preocupé por este problema, pero no hay pautas definitivas y / o buenos ejemplos disponibles para aprender.

Todas las opiniones son bienvenidas.

Tiendo a agrupar la funcionalidad en mis aplicaciones Laravel en ‘componentes’ autocontenidos. Por ejemplo, he estado trabajando en la funcionalidad de la campaña de correo electrónico para una aplicación recientemente, así que coloque la clase de proveedor de servicios, modelos, clases de servicio en una carpeta en la aplicación / Correo electrónico .

Teniendo esto en cuenta, organizo mis traducciones de manera similar. Entonces, aunque en este proyecto no estamos traduciendo cadenas, si estuviéramos, crearía un archivo resources / asset / lang / en / email.php , y pondría cadenas traducidas para el componente de correo electrónico allí.

Entonces, en otro proyecto, la estructura de mi directorio podría verse así:

  • / recursos
    • / lang
      • / en
        • auth.php
        • email.php
        • eventos.php
        • noticias.php
        • paginación.php
        • contraseñas.php
        • validation.php

Espero que esto ayude.

En mi experiencia, no hay ninguna razón para tener grupos diferentes, aparte de tratar de usar sus traducciones en otro lugar. Por lo general, coloco todos los mensajes de mis proyectos en un grupo llamado app y para cada una de mis bibliotecas compartidas, uso un nombre de grupo diferente (porque podría usarlos en otros proyectos). Un ejemplo de un mensaje de inicio de sesión fallido en mi sitio web sería

 trans('app.username_and_password_do_not_match') 

y si está en una biblioteca de terceros llamada Auth, sería

 trans('auth.username_and_password_do_not_match') 

Y recuerde escribir el mensaje completo como su clave de mensaje en lugar de usar nombres cortos (como app.login.fail ). De esta manera, no necesita revisar el contenido del sitio web para cada traducción.

No entendí completamente tu último problema, así que es posible que desees aclararlo un poco.

Iría con la opción # 4, así que tendrías algo como esto:

 /lang/ /en messages.php words.php /fr message.php words.php /de messages.php words.php 

Esto hace algunas cosas:

  • Se segmenta todo muy claramente. Sabes en qué idioma encontrar dónde. Y sabes lo que está en el archivo asociado con el idioma.
  • Lo anterior facilita el mantenimiento en el futuro porque puedes encontrar cosas.
  • Le proporciona archivos, por idioma, que se pueden traducir por separado.
  • Pone todo el mensaje en un lugar claramente definido.

Una cosa a tener en cuenta, es que si su aplicación se vuelve REALMENTE grande y REALMENTE internacional, es posible que desee utilizar códigos de idioma ISO en su lugar. Por ejemplo, el portugués europeo (pt_PT) y el portugués brasileño son diferentes y con una audiencia global probablemente querrá cubrir ambos.