2008-12-05 3 views
7

He presentado una solicitud en Microsoft Connect sobre el formato de las fechas ("DateTime Formatting should caluclate the correct suffix for the day"). Básicamente, quería tener un código de cadena de formato para agregar el sufijo al número del día. Por lo tanto, "1 de enero" se formateará "1 de enero" y "2 de enero" formateó "2 de enero", etc.¿Debería Microsoft evitar la implementación de una función en .Net simplemente porque la internacionalización es demasiado difícil?

Esto es bastante fácil de hacer para el caso inglés; sin embargo, Microsoft rechazó la idea con el argumento de que lo haría ser demasiado duro para internacionalizarse.

Me preguntaba si la gente está de acuerdo en que es razonable que Microsoft dificulte la vida de los programadores que escriben únicamente para un mercado inglés, simplemente porque no pueden atender el mercado no inglés.

Edit: Ok, acepto el argumento de que hay un marco para hacer lo que quieran. Estaba pidiendo más por un sentido ideológico. También recuerde que existe una alternativa fácil para las culturas no inglesas, que es no agregar nada, lo que hace que las personas no estén peor de lo que están ahora.

Editar 2: Para mí esto es más que una hora de trabajo. Tengo que apoyar código que se ve algo como esto:

 DateTime minDate = new DateTime(2003, 12, 10); 
     string errorMessage = ValidationMessageResource.DateTooEarly;    
     Console.WriteLine(String.Format(errorMessage, minDate)); 

tengo ningún control sobre el contenido del archivo de recursos y la cadena de recursos es a menudo algo como esto "La fecha no debe ser antes de {0: D}". Para hacer esto, necesitaría implementar mi propia clase IFormatProvider, que debería admitir todas las cadenas de formato diferentes que acepta el formateador de Microsoft. Microsoft no parece haber dado una manera fácil de extender su formateador a través de la herencia.

Respuesta

8

Totalmente de acuerdo en que es razonable. No hay nada que le impida implementar el formato que desea en su propia biblioteca reutilizable.

+0

Aparte de tiempo, dinero y esfuerzo, por supuesto;) Véase la segunda edición en mi puesto de por qué No creo que esto sea trivial para mí implementar. –

2

¿El inglés correcto para el 1er, 2do y 3er elemento de una lista no es primero, segundo y tercero?

Puedo ver lo que quiere decir, pero es más un problema de contracciones de apoyo "no puede, no, no es" entonces un problema de fecha y hora.

18

1: Es su marco, cualquier cosa que elijan hacer es, por definición, razonable. No están obligados a proporcionarles nada que no sientan.

2: Las características que no se pueden internacionalizar son básicamente inútiles. Si lo agregasen solo para inglés, todo lo que lograrían es que el resto del mundo exigiría que se internacionalizara y, de repente, se verían mal por darle al resto del mundo un trato inferior.

3: es difícil de internacionalización. No puede suponer que cada idioma simplemente agrega un sufijo. Podría ser un prefijo, o podría cambiar partes completamente diferentes de la oración. (O, como señaló otro cartel, puede ser "primero" en lugar de 1er, por lo que incluso en inglés, no hay reglas rígidas. ¿Por qué deberían implementar su regla arbitraria, pero no otras, igualmente válidas para el inglés?)

3b: Si bien obviamente no te importa eso, Microsoft está comercializando .NET como un marco consciente de la internacionalización. Lo que significa que no pueden ignorar el 90% del mundo para satisfacer sus necesidades.

4: Te llevaría una hora codificar la versión solo en inglés para ti, ¿no?;)

5: No tiene nada que ver con DateTime. Es una propiedad general del formato de cadena de números en general.

6: Su suposición de que "si agregaron la función para inglés, nadie más estaría peor que ahora" es incorrecta. Los desarrolladores generalmente confían en .NET para comportarse correctamente. Si se agregó su sugerencia de formateo, los desarrolladores lógicamente esperarían que funcionara para todos los idiomas y configuraciones regionales y, por lo tanto, generaría resultados no válidos o inesperados para todos los idiomas distintos del inglés cuando el desarrollador espera que no exista ningún problema.

+0

1. Bien, 2. Buen punto, 3. No estaba pidiendo eso. 4. Tomaría más de una hora. Ver mi segunda edición para la publicación. –

1

Creo que tanto MS como ustedes hicieron buenos puntos.

Tiendo a estar de acuerdo con MS. El problema no hace la vida más difícil para el software que no es inglés. El verdadero problema sería que los nuevos métodos no funcionarían en diferentes idiomas, y eso no es aceptable. Una cosa es no tener una función, otra es tener una función que no funciona en ciertos casos.

Supongo que sería posible hacer funciones específicas del lenguaje. Tal vez algo así como la localización.Inglés.FechaFormatter Eso sería un buen compromiso, sin embargo, podría llevar a la escritura de software más difícil de localizar en el largo plazo.

+0

No necesitaría crear un nuevo formateador, simplemente omita el sufijo cuando no sabía qué poner. –

0

Microsoft no tiene la obligación de implementar el trabajo para usted. Tendrá que ser una de esas cosas que implementes a ti mismo en la parte superior de su marco.

1

Solo para darle una idea de lo difícil que es esto.

1 de enero solo es correcto para inglés inglés. La forma correcta en inglés de EE. UU. Es el 1 de enero.

Los canadienses probablemente se comprometan con 1er Janvier.

+0

Primero, ya cambian la fecha y el mes si usa DateTime.ToLongDateSting() o DateTime.ToString ("D") agregando mi solicitud extra no sería difícil. 2º 1er Janvier no es inglés, así que no estoy discutiendo por eso. –

+0

Sí, pero lo que solicitó no es realmente correcto en la configuración regional de EE. UU. Es solo correcto en el Reino Unido y partes del antiguo imperio. Entonces, hay problemas incluso en el mundo de habla inglesa. MS solo está tratando de evitar un mundo de dolor aquí. –

+0

Esto es engañoso o irrelevante - strftime() en C solo necesita agregar% o para ordinal con dígitos, y% O (excepto que está en uso) para el número ordinal escrito en su totalidad, y luego las fechas pueden formatearse usando una cadena de formato con los metasímbolos apropiados Igual que el resto puede. –

1

Como dijo Jalf, no tardaría demasiado tiempo para contar algo en inglés. A continuación, puede utilizar esto como un proyecto de código abierto (si no se ha hecho antes). Los desarrolladores que entienden el formato de otros países podrían contribuir, por lo que no necesitaría saber todo antes de comenzar.

+0

Esto tomaría un tiempo en mi caso. Ver la segunda edición de mi publicación. –

3

"Me preguntaba si la gente está de acuerdo en que es razonable que Microsoft dificulte la vida de los programadores que escriben únicamente para un mercado inglés, simplemente porque no pueden atender el mercado no inglés".

Creo que estás siendo un poco extremo y, en mi opinión, es realmente un caso extremo. Este tipo de formato de fecha es como pedir a Microsoft un formateador de código postal o una clase de Dirección. Seguro que hay una convención para la mayoría de los países para formatear códigos postales y direcciones, pero eso no significa que MS tenga que implementarla. Tiene el marco al alcance de su mano para construir este tipo de estructuras de datos.

+0

Estoy de acuerdo, sin embargo, MS ya han pasado la mayor parte del tiempo con el formato DateTime. Siento que no han completado el trabajo en lugar de no haberlo iniciado. –

+0

Y su sugerencia completaría el trabajo ¿cómo, exactamente? ¿Implementando una característica mal definida para * un * idioma? – jalf

1

La función C para formatear fechas es strftime(). Esto toma una cadena de formato con notaciones '%x' para indicar las partes de la fecha a formatear y cómo formatearlas. Sería posible agregar '%o' como un elemento de formato para el número de día ordinal con dígitos (1 °, 2 °, 3 °, ...), y una alternativa (lógicamente '%O' pero creo que ya está en uso) para la versión explicada (primero, segundo, ...). Esto podría luego globalizarse de la misma manera que cualquier otra parte del formato de fecha.El resultado predeterminado para '%o' podría perfectamente ser 'sin sufijo' si la configuración regional no tiene información sobre cómo se escriben los números ordinales; incluso podría usar el número sin sufijo para 'deletreado'

La funcionalidad equivalente existe en otros marcos de lenguaje: podría proporcionarse tan fácilmente en cualquiera de ellos.

(Si alguien quisiera ordinalize meses - el primer mes de 2009 - a continuación, se necesitaría otro símbolo.)

Cuestiones relacionadas