realizar - ¿Debería Microsoft evitar implementar una característica en.Net simplemente porque la internacionalización es demasiado difícil?
tipos de estrategias de internacionalizacion (9)
Planteé una solicitud en Microsoft Connect sobre el formato de las fechas ("El formato de fecha y hora debe calcular el sufijo correcto para el día "). Básicamente, quería tener un código de cadena de formato para agregar el sufijo al número del día. Entonces, "1 de enero" se formateará "1 de enero" y "2 de enero" formateará "2 de enero", etc.
Esto es bastante fácil de hacer para el caso inglés, sin embargo, Microsoft ha rechazado la idea con el argumento de que sería demasiado difícil internacionalizarse.
Me preguntaba si las personas están de acuerdo en que es razonable que Microsoft les haga la vida más difícil a los programadores de inglés que escriben únicamente para un mercado inglés, simplemente porque no pueden atender el mercado no inglés.
Editar: 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. Necesito un código compatible con algo como esto:
DateTime minDate = new DateTime(2003, 12, 10);
string errorMessage = ValidationMessageResource.DateTooEarly;
Console.WriteLine(String.Format(errorMessage, minDate));
No tengo control sobre el contenido del archivo de recursos y la cadena de recursos suele ser algo así como "La fecha no debe ser anterior a {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.
¿Entonces el inglés correcto para el 1er, 2do y 3er elemento de una lista no es primero, segundo y tercero?
Puedo ver a qué te refieres, pero es más un problema de contracciones de apoyo que "no puede, no lo hará, no", sino un problema de fecha y hora.
Completamente de acuerdo que es razonable. No hay nada que le impida implementar el formato que desea en su propia biblioteca reutilizable.
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.
Sin embargo, 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.
Microsoft no tiene ninguna obligación de implementar el trabajo por usted. Tendrá que ser una de esas cosas que implementes a ti mismo en la parte superior de su marco.
1: Es su marco, cualquier cosa que decidan hacer es, por definición, razonable. No están obligados a proporcionarles nada que no sientan.
2: Las características que no pueden ser internacionalizadas 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 internacionalizarse. 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: aunque obviamente no te importa eso, Microsoft está comercializando .NET como un marco que reconoce 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 cadenas 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.
Como dijo Jalf, no tardaría mucho en 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.
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 factible agregar '' %o '' como 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 el ''deletreado''
La funcionalidad equivalente existe en otros marcos de lenguaje: podría proporcionarse tan fácilmente en cualquiera de ellos.
(Si alguien quiere ordenar meses, el primer mes de 2009, entonces necesitaría otro símbolo).
Solo para darte una idea de lo difícil que es esto.
El 1 de enero solo es correcto para el inglés británico . La forma correcta en inglés de EE. UU. Es el 1 de enero.
Los canadienses probablemente se comprometan con 1er Janvier.
"Me preguntaba si la gente está de acuerdo en que es razonable que Microsoft les haga la vida más difícil a 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.