2009-08-22 26 views
8

Escenario¿Formato de URL para aplicación web internacionalizada?

El servidor web recibe una solicitud de http://domain.com/folder/page. El encabezado Accept-Language nos dice que el usuario prefiere el griego, con el código de idioma el. Eso está bien, ya que tenemos una versión griega de page.

Ahora podríamos hacer uno de estos procedimientos con la URL:

  1. devolver una versión griega manteniendo la URL actual: http://domain.com/folder/page
  2. Redirigir a http://domain.com/folder/page/el
  3. Redirigir a http://domain.com/el/folder/page
  4. Redirigir a http://el.domain.com/folder/page
  5. Redirigir a http://domain.com/folder/page?hl=el
  6. ... otras alternativas?

¿Cuál es la mejor? Pros, contras desde la perspectiva del usuario? perspectiva del desarrollador?

+1

Véase también http://stackoverflow.com/questions/449010 – Gumbo

+0

6. Redirigir a 'http: // dominio.com/carpeta/página.el' (estilo de nombre de archivo de mod_negotiation) – Boldewyn

+8

Tenga cuidado de no confiar en Aceptar -Lenguaje encabezado demasiado. Hay una gran cantidad de usuarios que no aceptarán amablemente una suposición automática sobre su idioma basada en ese encabezado. Asegúrese y proporcione una forma obvia de seleccionar el idioma apropiado en cada página si el idioma detectado es incorrecto. –

Respuesta

15

No iría por la opción 1, si sus páginas están disponibles públicamente, es decir, no es necesario que inicie sesión para ver las páginas. El motivo es que un motor de búsqueda no escaneará las diferentes versiones de idioma de la página. La misma razón va contra la opción n. ° 5. Es menos probable que un motor de búsqueda identifique dos páginas como páginas separadas, si la identificación del idioma va en la cadena de consulta.

Veamos la opción 4, colocando el idioma en el nombre de host. Usaría esa opción si las versiones en diferentes idiomas del sitio contienen contenido completamente diferente. En un sitio como Wikipedia, por ejemplo, la versión griega contiene su propio conjunto completo de artículos, y la versión en inglés contiene otro conjunto de artículos.

Así que si no tiene contenido completamente diferente (que no parece de su publicación), se queda con la opción 2 o 3. No sé si hay argumentos convincentes para uno más el otro, pero no. 3 se ve mejor en mis ojos. Entonces eso es lo que usaría.

Pero solo un comentario para inspirarse. Actualmente estoy trabajando en una aplicación web que tiene 3 partes principales, una pública y dos partes para dos tipos de usuarios diferentes. He elegido el esquema de URL siguiente (con baño en referencia a la lengua, por supuesto):

http://www.example.com/en/x/y/z for the public part. 
http://www.example.com/part1/en/x/y/z for the one private part 
http://www.example.com/part2/en/x/y/z for the other private part. 

La razón de esto es que si tuviera que dividir las tres partes arriba en aplicaciones por separado, será una reconfiguración simple en el servidor web cuando tengo el nombre de la parte en la parte superior de la ruta. P.ej. si tuviéramos que usar un sistema CMS comercial para la parte pública del sitio

Editar: Otro argumento en contra de la opción no. 1 es que si SÓLO escuchas el idioma de aceptación, no estás dando una opción al usuario. El usuario puede no saber cómo cambiar el idioma configurado en un navegador, o puede estar utilizando una configuración de computadora frinds en un idioma diferente.Al menos debe darle al usuario una opción (almacenarlo en una cookie o en el perfil del usuario)

+0

Mi pregunta se supone que es independiente de cómo el usuario selecciona el idioma, haciendo clic en un enlace o cambiando el idioma del navegador . –

+0

Acerca del número 2, ¿no sería una URL extraña: ** .../carpeta/página? Par1 = x & par2 = y/el **. ¿Funcionaría? –

+0

.../folder/page? Par1 = x & par2 = y/el - No veo por qué no debería poder hacer que funcione.En cuanto a si se ve extraño o no, las personas rara vez escriben una URL completa, y no es realmente una necesidad que una URL sea agradable a la vista. Pero no es ideal para las optimizaciones de los motores de búsqueda, así que si el contenido se encuentra en los motores de búsqueda, recomendaría uno de los otros enfoques. Pero si el SEO no es una preocupación, y es más fácil de implementar, yo iría por eso. Solo recuerde que cambiar una URL después de que se inicie una característica romperá los marcadores de personas. – Pete

0

prefiero 3 o 4

2

El número cuatro es la mejor opción, ya que especifica el código de idioma bastante temprano. Si va a proporcionar alguna redirección, siempre asegúrese de usar una etiqueta de enlace canónica.

2

Mi elección es # 3: http://domain.com/el/folder/page. Parece ser el más popular en la web. Todas las otras alternativas tienen problemas:

  1. http://domain.com/folder/page --- ¿Malo para SEO?
  2. http://domain.com/folder/page/el --- No funciona para páginas con parámetros. Esto se ve raro: ... página? Par1 = x & par2 = y/el
  3. http://domain.com/el/folder/page --- Se ve bien!
  4. http://el.domain.com/folder/page --- Se necesita más trabajo para implementar, ya que requiere agregar subdominios.
  5. http://domain.com/folder/page?hl=el --- ¿Malo para SEO?
+0

¿Podría explicar su explicación de la segunda URL, por favor? – Gumbo

+0

Agregó un ejemplo arriba. –

+1

Creo que sería más adecuado consultar con 'page/el? Par1 = x & par2 = y'. Eso es mucho más fácil de trabajar. – Brian

2

Elija la opción 5, y no creo que sea malo para SEO.

Esta opción es buena, ya que muestra que el contenido de ejemplo:
http://domain.com/about/corporate/locations es el mismo que el contenido en
http://domain.com/about/corporate/locations?hl=el excepto que el idioma es diferente.
El parámetro hl debe anular el encabezado Accept-language para que el usuario pueda controlar fácilmente el asunto. El encabezado solo se usará cuando falta el parámetro hl. La vinculación concedida es un poco complicada por esto, y probablemente debería abordarse a través de una cookie que mantendría la redirección en el idioma elegido por el parámetro hl (ya que puede haber sido modificado por el usuario desde la configuración Accept-language, o teniendo todos los enlaces en la página se procesan para agregar en el parámetro hl actual.

Los problemas de SEO se pueden solucionar creando archivos de índice para todo lo que stackoverflow hace, estos podrían incluir varios conjuntos de índices para los diferentes idiomas, con suerte aparece en los resultados para el idioma no predeterminado

El uso de 1 quita el diferenciador en la URL. El uso de 2 y 3 sugiere que la página es dif. diferente, posiblemente más allá del lenguaje, como es wikipedia. Y el uso de 4 sugiere que el servidor en sí está separado, tal vez incluso geográficamente.

Debido a que existe una correlación sorprendentemente pobre de la ubicación geográfica con las preferencias de idioma, la cuestión de proporcionar servidores geográficamente cercanos debería dejarse en una configuración de CDN adecuada.

1

Depende. Elegiría personalmente el número cuatro, pero muchas empresas exitosas tienen diferentes formas de lograrlo.

  • Wikipedia utiliza subdominios para varios idiomas (el.wikipedia.org).
    • Lo mismo ocurre con Yahoo (es.yahoo.com en español), aunque no es compatible con el griego.
    • también lo hace Gravatar (el.gravatar.com)
  • Google utiliza un/intl/EL/directorio.
  • Apple utiliza un/gr/directorio (aunque en Inglés y se limita a una página de iPhone)

Es realmente depende de ti. ¿Qué crees que les gustará más a tus clientes?

6

yo elegiría número 3, redirigir a http://example.com/el/folder/page, porque:

  1. Selección de idiomas es más importante que una selección de páginas, el idioma seleccionado de este modo debe ir por primera vez en una verdadera URL legible.
  2. Solo un dominio obtiene todas las relaciones públicas de Google. Eso es bueno para SEO.
  3. Puede anunciar su sitio localmente con un código de idioma incorporado. P.ej. en Grecia, se anunciaría como http://example.com/el/, por lo que cada visitante local accederá a un sitio en Grecia y evitaría la frustración de elegir el idioma.

Alternativamente, usted puede ir para número 5: está bien para Google y amigos, pero no tan bien para un usuario.

Además, debemos abstenernos de redirigir a un usuario a cualquier parte, a menos que sea necesario. Por lo tanto, en mi opinión, un usuario que abre http://example.com/folder/page no debería obtener una redirección, sino una página en un idioma predeterminado.

+0

En su último párrafo parece que prefiere la alternativa número 1? –

+0

No creo que lo haga, solo que el URL predeterminado debe entregarse en un idioma predeterminado. –

1

Ninguno de ellos. Un "usuario normal" no entendería (y así lo recuerda) ninguna de esas abreviaturas.

En orden de preferencia, me gustaría sugerir:

  1. http://www.domain.gr/folder/page
  2. http://www.domain.com/
  3. http://domain.com/gr/folder/page
+0

No esperaría que un usuario los recuerde ya que redirigiría de domain.com a la URL específica del idioma. –

+0

En ese caso, la opción 2 no muestra nada que el usuario no necesite ver. –

+0

solo mis dos centavos, por experiencia propia que no muestra nada puede ser un verdadero dolor en algunos sitios web. En particular, los sitios web que lo redireccionan a la página de inicio cuando cambia de idioma. Luego debe volver a intentar recuperar su página, lo que no siempre es fácil si proviene de un enlace externo. Por lo tanto, si puedo, me gustaría poder cambiar la URL. El caso de uso genérico para esto es, particularmente en 'sitios de gobierno'. Si quiero enviar la url a un amigo que no entiende el idioma de la página. Es un caso de uso particular, y se debe a un comportamiento de lenguaje de cambio malo. – HeDinges

1

3 o 4.

3: Puede ser fácilmente tratado con el uso htaccess/mod_rewrite. El único inconveniente es que tendría que escribir algún método para inyectar automáticamente el código de idioma como el primer segmento del URI.

4: Probablemente el mejor método. Usando encabezados de host, todo puede enviarse a la misma aplicación/contenido web, pero luego puede usar el código para extraer el código de idioma e ir desde allí.

Simples. ;)

Cuestiones relacionadas