La mejor manera de crear directorios virtuales en sitios multilingües

Question

Tengo un sitio que finalmente admitirá 4 idiomas y 2 países (EE. UU. y Canadá, inglés y español)

Me pregunto cuál es la mejor manera de configurar la estructura del directorio.

En este momento tengo un sitio raíz llamado site.com:

Esto te llevará a una página donde eliges tu país e idioma.

Idealmente, quiero tener el directorio así:

site.com/ca/en/ (Canada English)
site.com/ca/fr/ (Canada French)
site.com/us/en/ (US English)
site.com/us/es/ (US Spanish)

Pero eso significará que colocaré un directorio virtual "ca" y "us" y directorios virtuales de idiomas dentro de eso.¿ES esa una buena práctica, o debería hacer algo como:

site.com/ca-en/ (Canada English)
site.com/ca-fr/ (Canada French)
site.com/us-en/ (US English)
site.com/us-es/ (US Spanish)

editar:He hecho lo siguiente:

Hay un directorio ficticio:/ca/ y /us/ en la aplicación.Ambos tienen un archivo default.aspx que es solo una redirección.En mi caso, los redirijo a sus sitios en inglés:

Por ejemplo:sitio.com/ca/ -> sitio.com/ca/en/ sitio.com/us/ -> sitio.com/us/en/

Si ingresa site.com, se lo dirigirá a una página de selección de idioma.Básicamente, uso una expresión regular en Global.asax en cada solicitud para buscar la cadena de idioma/cultura.

Esto tiene los siguientes beneficios.Separación de países.Por lo tanto, tiene control sobre site.com/ca/ o site.com/us/ y puede proporcionar una URL simple para cada país.

De todos modos, los directorios virtuales /en/, /fr/ y /es/ se encuentran dentro de las carpetas físicas de sus respectivos países.

Entonces tienes lo siguiente (los directorios virtuales están en atrevido):

sitio.com/ca/es/ (predeterminado) sitio.com/ca/fr/ sitio.com/us/es/ (predeterminado) sitio.com/us/es/

Lo que esto significa es que necesita tener cinco aplicaciones (idénticas), excepto que puede usar la URL para obtener el idioma y el país actuales (y apuntarlo a la base de datos correcta).

Answer 1

Bueno, quieren que la URL sea diferente para cada sitio.

Esencialmente, en realidad es un sitio (por razones de mantenimiento) y estamos usando la globalización para determinar qué cadena de conexión usar (diferentes bases de datos, estructuras idénticas en cada una).

Cada vez que publiquemos, lo haré en cuatro ubicaciones.Aplicación idéntica.

La globalización usando una URL SUENA como una buena idea, pero no creo que funcione correctamente, e incluso si lo hiciera, no ofrece un buen enlace para marcar.(Un francés envía un enlace a otro francés utilizando un ordenador configurado en inglés).Hay otras implicaciones, pero hay una razón por la que sitios como Apple y Microsoft usan URL diferentes para cada idioma/cultura.

En cada inicio de sesión, verifico la URL y configuro las cadenas de conexión en consecuencia.

AL FINAL, simplemente puse un directorio /ca/ y /us/ en la aplicación principal, agregué algunos directorios virtuales a cada idioma y realicé una redirección de respuesta a la página "elegir un idioma".

Quizás no sea la mejor solución, pero parece estar funcionando.

Otro beneficio de hacerlo de esta manera es que si hay alguna página especial que solo se aplica a un sitio, solo se puede agregar a ese sitio.

Answer 2

¿Por qué no tener un sitio y comprobar el ajuste del cliente (request.servervariables / HTTP_ACCEPT_LANGUAGE) por lo que el idioma preferido de usar y con el construido en la globalización en asp.Net?

Si se mostrará el contenido totalmente diferente dependiendo del país / idioma entonces puedo entender por qué los separa de esa manera.

Answer 3

nomenclatura generalmente aceptada para la localización es ll-CC para el código de lenguaje guión de código de país. ejemplo: en-US, aunque es-sería probablemente el defecto con También son dignos en-GB o en-CA como retrocesos ... ES-MX etc. Puede ser mejor usar subdominios sin embargo, lo que permitiría la ruptura de los recursos sin reglas de equilibrio de carga complejas en frente. por ejemplo: us.en.yoursite.com ... esto también permite una distribución más fácil de servidores en un entorno WebFarm. Yo sugeriría que tiene el código real del mismo con un cambio de configuración por sitio para que coincida con la localización. A continuación, utilice un recurso de localización que se pasa en una clave textual, y la traducción de la lengua que se resuelva sobre la base de patrón de localización del sitio. Nota:. Net, y otras plataformas ofrecen opciones de localización de recursos construidos en