La tecla de acceso 'n' lleva a la navegación de la página. Ir al inicio del contenido.

Este documento es una traducción. En caso de discrepancias o errores, la única versión normativa es el último original en inglés. Los derechos de autor originales corresponden al W3C, como puede verse al final de la página.

Traductor: Spanish Translation Team, Spanish Translation US.

s_gotoW3cHome Internacionalización
 

Formatos de fechas

Audiencia de destino: codificadores de XHTML/HTML (que usen editores o lenguaje de script), desarrolladores de sistemas de escritura (PHP, JSP, etc.), gerentes de proyectos web, y todo aquel que quiera saber cómo trabajar con formatos de fechas internacionales.

Pregunta

¿Cómo puedo preparar mis páginas web para que muestren distintos formatos de fechas internacionales?

Información preliminar

El formato de las fechas puede resultar confuso para aquellos que visitan un sitio web, hablan distintos idiomas y provienen de diferentes regiones. El formato MM/DD/AA es exclusivo de Estados Unidos. La mayor parte de los países europeos utilizan el formato DD/MM/AA. Japón emplea el formato AA/MM/DD. Los separadores pueden ser barras, guiones o puntos. Según algunos estilos lingüísticos regionales, se completan los espacios con ceros; según otros, no se escriben. Si un japonés lee una página web redactada en inglés estadounidense desde un sitio web de Alemania que muestra la fecha 03/04/02, ¿cómo debe interpretar la información?

Respuesta

El primer impulso puede ser asumir que el problema se resolverá durante el proceso de localización de las páginas web, es decir, dejar que lo resuelva el traductor. Resista ante este impulso. ¿Realmente desea mantener copias separadas de documentos para Estados Unidos y para el Reino Unido que simplemente tengan distintos formatos de fechas? En caso de que tenga que trabajar con usuarios plurilingües como en el ejemplo anterior,

existen tres opciones a tener en cuenta. Todas tienen ventajas y desventajas:

  1. Usar un formato neutral para cuestiones lingüísticas regionales
  2. Procurar que el mes y el año resulten evidentes
  3. Utilizar el encabezado HTTP Accept-Language

Opción uno: usar un formato neutral para cuestiones lingüísticas regionales

La norma ISO 8601 especifica un formato AAAA-MM-DD. 2003-04-02 es más claro que 03/04/02. (Algunos prefieren modificar la norma ISO 8601 y utilizar una forma abreviada al indicar el mes para que resulte más claro, por ejemplo, 2003-abr-02. Sin embargo, esta variante ya no es neutral para cuestiones lingüísticas regionales).

Pros:

Contras:

Opción dos: procurar que el mes y el año resulten evidentes

Para hacerlo, utilice un nombre para el mes (en forma abreviada o no) y 4 dígitos para los años del calendario gregoriano. Por ejemplo, 2 de abril de 2003.

Pros:

Contras:

Opción tres: utilizar el encabezado HTTP Accept-Language

El encabezado HTTP Accept-Language sólo especifica las preferencias de idioma del usuario, pero se utiliza habitualmente para establecer preferencias de estilos lingüísticos regionales.

Este método funciona adecuadamente para documentos web generados en forma dinámica cuando se debe insertar en una página una fecha proveniente de algún sistema de almacenamiento back-end, siempre que las expectativas del usuario en términos de formato de fecha sean claras. La conveniencia de esta alternativa es una cuestión que depende más del contexto lingüístico que simplemente de la configuración del navegador del usuario. Por ejemplo:

La manera de resolverlo dependerá del entorno de desarrollo. A continuación se incluyen sugerencias para algunos entornos comunes.

Java/JSP

Llamar al método getLocale del objeto ServletRequest o HttpServletRequest. Utilizar el objeto devuelto Locale para llamar al DateFormat. Se debe tener en cuenta que en el formato SHORT (abreviado) únicamente se utilizan números. Si desea un formato sin ambigüedades, utilice el formato FULL (completo). Para algunos estilos lingüísticos regionales, aun el formato LONG (extenso) es completamente numérico.

Consulte también ICU4J, ya que contiene datos más actualizados (y más funcionalidades) que las rutinas JDK.

ASP

Usar Request.ServerVariables("HTTP_ACCEPT_LANGUAGE") para acceder a las preferencias del usuario. Analizar la sintaxis de los primeros estilos lingüísticos regionales de la lista de parámetros aceptados. Tendrá que hacer su propia conversión del código alfabético del estilo lingüístico regional a un Identificador numérico de estilos lingüísticos regionales. Configurar Session.LCID según el valor resultante. Llamar a FormatDateTime para establecer el formato de la fecha.

Usar vbLongDate para evitar ambigüedades.

Perl

Usar $ENV{"HTTP_ACCEPT_LANGUAGE"} para acceder al idioma de preferencia. Usar POSIX:strftime para dar formato a los valores de fechas. Tendrá que hacer su propia conversión del valor de los idiomas aceptados a una secuencia de formatos de fechas.

Resumen

No existe una solución ideal para este problema. Se deben evaluar las opciones y seleccionar la alternativa más adecuada según sus preferencias y su situación particular.

Si considera que los datos pueden resultar ambiguos para el usuario, siempre es preferible emplear nombres explícitos para referirse a los meses y cifras de cuatro dígitos al indicar los años para fechas en formato gregoriano o, al menos, indicar en la página cómo se deben leer las fechas.

Es posible volver a formatear las fechas mediante el empleo de técnicas dinámicas para lograr una correspondencia con el contexto lingüístico de la página.

A propósito

Existen partidarios de la creación de una etiqueta de <fecha> en la que se mostrarían las fechas de acuerdo con los estilos lingüísticos regionales del agente de usuario. Esto queda sujeto a las mismas cuestiones prácticas mencionadas para la generación de fechas en forma dinámica en el ejemplo del idioma japonés. El formato adecuado generalmente depende mucho más del contexto lingüístico de la página que de la plataforma del usuario.

Dinos qué piensas (en Inglés).

Suscripción a feed RSS.

Nuevos recursos

Noticias de la página de inicio

Twitter (Noticias de la página de inicio)

‎@webi18n

Lecturas complementarias

De: Lloyd Honomichl, Lionbridge. Cambiado por: Richard Ishida, W3C. Traductor: Spanish Translation Team, Spanish Translation US..

XHTML 1.0 válido
CSS válido
Codificado en UTF-8

Traducido del inglés con fecha 2007-07-04. Traducción modificada por última vez el 2010-10-13 09:17 GMT.

Para ver el historial de cambios del documento, busque qa-date-format en la bitácora de internacionalización.